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1.  Introduction 


This  Airborne  Reconnaissance  Information  Technical  Architecture  (ARITA) 
document,  in  conjunction  with  the  DoD  Joint  Technical  Architecture  (JTA) 
document,  provides  the  technical  foundation  for  migrating  airborne 
reconnaissance  systems  towards  the  objective  architecture  identified  in  the 
Integrated  Airborne  Reconnaissance  Strategy  and  in  the  various  program  plan 
documents  of  the  Defense  Airborne  Reconnaissance  Office  (DARO).  That 
objective  architecture  (depicted  in  Figure  1-1)  is  a  high-level  vision  of  the 
migration  plans  and  major  thrusts  to  achieve  the  capabilities,  connectivities,  and 
interoperability  required  of  airborne  reconnaissance  systems.  In  concert  with 
space-based  systems,  this  objective  architecture  will  support  the  warfighter  with 
responsive  and  sustained  intelligence  data  from  anywhere,  day  or  night,  regardless 
of  weather.  The  objective  architecture  is  best  described  as  a  responsive,  full 
spectrum  information  architecture  centered  on  satisfying  the  commander’s 
reconnaissance  information  requirements  across  the  operational  continuum. 

Migrating  from  today’s  stove-piped  systems  to  the  objective  architecture  by  2010 
is  highly  dependent  upon  achieving  the  concepts  promulgated  by  Cfl  For  The 
Warrior,  other  DoD  technical  architectures,  and  Service/Agency  operational 
architectures.  These  architectures,  including  the  ARITA,  result  in  system 
architectures  and  migration  plans  which  include  performance  capabilities, 
development  and  modification  schedules,  and  projected  costs.  The  system 
architectures  and  migration  plans  are  in  turn  impacted  by  Service/ Agency 
program  priorities,  OSD  and  JCS  guidance/decisions,  and  Congressional  budget 
decisions  and  program  direction  resulting  in  overall  DARO  investment  strategies. 
These  strategies  ensure  that  airborne  reconnaissance  systems  will  become 
interoperable,  integrated  with  the  warfighter  and  intelligence  community  systems, 
and  capable  of  “delivering  the  right  data,  to  the  right  user,  at  the  right  time.” 

This  section  describes  the  purpose,  background,  and  scope  of  the  ARITA 
document;  describes  the  relationship  between  three  levels  of  architectures  and  two 
reference  models;  gives  the  criteria  for  selecting  standards,  and  summarizes 
what’s  in  this  document. 
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1.1  Purpose 

The  ARITA  supports  four  mutually  supporting  objectives  that  provide  the 
framework  for  meeting  warfighter  requirements.  First  and  foremost,  the  ARITA 
provides  the  foundation  for  seamless  flow  of  information  and  interoperability 
among  all  airborne  reconnaissance  systems  and  associated  ground/surface  systems 
that  produce,  use,  or  exchange  information  electronically.  Second,  it  establishes 
the  minimum  set  of  standards  and  technical  guidelines  for  development  and 
acquisition  of  new,  improved,  and  demonstration  systems  to  achieve 
interoperability,  with  reductions  in  costs  and  fielding  times  that  would  be 
unachievable  without  a  technical  architecture.  Third,  it  ensures  interoperability 
with  warfighter  C4I  systems  and  enables  development  of  new  or  alternative 
connectivities  and  operational  plans  for  specific  mission  scenarios  for  airborne 
reconnaissance  systems.  And  fourth,  it  provides  the  framework  for  attaining 
interoperability  with  space-based  and  other  intelligence,  surveillance,  and 
reconnaissance  (ISR)  systems. 

Specific  goals  for  the  ARITA  are: 

•  Maximize  interoperability; 

•  Minimize  duplication  of  development; 

•  Be  adaptable  to  new  requirements,  preferably  through  software 
reconfiguration; 

•  Be  extensible  by  enabling  modular  increases  in  system  capabilities; 

•  Leverage  commercial  technology  and  standards; 

•  Allow  functionality  to  be  optimized  for  mission  and  platform; 

•  Make  provisions  for  retaining  required  legacy  systems; 

•  Provide  mechanisms  for  cross-sensor  cueing  to  improve  ISR 
capability;  and 

•  Support  multiple  platform  operations  using  like  or  dissimilar  platforms 
and  sensors  improve  precise  geolocation. 

The  ARITA  applies  to  all  airborne  reconnaissance  and  associated  ground/surface 
systems.  Senior  Officers/Officials,  Service  Acquisition  Executives  (SAE), 
Program  Executive  Officers  (PEO),  System  Program  Office  (SPO)  Directors, 
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Program/Product  Managers  (PMs),  Advanced  Technology  Demonstration  (ATD) 
Managers,  and  Advanced  Concept  and  Technology  Demonstration  (ACTD) 
Managers  are  responsible  for  incorporating  ARITA  standards  into  their  respective 
programs.  Developers  will  use  the  ARITA  to  ensure  that  products  meet 
interoperability,  performance,  and  sustainment  criteria.  Operations  and 
Intelligence  organizations  will  use  the  ARITA  in  developing  requirements, 
operational  plans  and  functional  descriptions.  Technology  demonstrators  will  use 
the  ARITA  to  ensure  that  the  fielding  of  “good  ideas”  and  “new  technologies”  are 
not  unduly  delayed  by  the  cost  and  time  required  for  wholesale  reengineering  to 
meet  interoperability  requirements  and  integrate  with  other  airborne 
reconnaissance  and  warfighter  systems. 

1.2  Background 

The  evolution  of  national  military  strategy  in  response  to  post  cold  war  era  events 
combined  with  the  economic  reality  of  a  shrinking  budget  has  resulted  in  a  new 
vision  for  the  Department  of  Defense  (DoD).  This  vision  is  most  commonly 
known  as  C*I  For  The  Warrior  concept  as  documented  in  Joint  Pub  6-0.  Under 
this  concept,  there  is  increased  reliance  on  information  systems  to  provide  the 
decisive  edge  in  combat  and  to  improve  the  military  worth  of  DoD  systems. 

The  Services  have  developed  corresponding  visions  in  the  following  documents: 

•  The  Army  Enterprise  Strategy:  The  Vision 

•  The  Air  Force  Strategy:  Horizon  FY95 

•  The  Navy  Strategy:  Copernicus  Forward 

•  The  Marine  Corps  Strategy:  MAGTF/C4I 

The  Chairman,  Joint  Chiefs  of  Staff  is  developing  the  “Joint  Vision  2010”  which 
envisions  seamless  integration  of  all  ISR  systems  to  achieve  precision 
engagement,  dominant  maneuver,  focused  logistics,  and  full  dimensional 
protection.  To  attain  that  vision,  airborne  reconnaissance  systems  must  achieve 
and  maintain  interoperability  across  a  continuum  of  six  dimensions  at  once: 

•  Reconnaissance  (and  surveillance)  Systems:  Space,  airborne,  ground, 
and  surface 
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•  Command,  Control,  Communications,  Computers  and  Intelligence 
(C4I)  &  Support:  Command  and  control,  intelligence,  logistics,  and 
Warfighter  support 

•  Forces:  National  Command  Authority,  commanders,  and  warfighters 

•  Joint/Coalition:  Coalition,  Joint,  CINC,  Joint  Task  Force,  and  Services 

•  Power  Projection:  Sustaining  base,  split  base,  and  forward  based 

•  Time/Technology:  Backward  and  forward  compatibility 


Coalition  -  Joint  -  CINC  -  TF  -  Services 
Joint/Coalition 

C4I  -  Intel  -  Log  -  Warfighter  Spt 
C4I  and  Support 

Space  -  Airborne  -  Surface  -  Ground 
Reconnaissance  Systems 


Backward  -  Compatibility  -  Forward 
Time/Technology  Generations 
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Figure  1-2:  The  Dimensions  of  Interoperability 

To  achieve  interoperability,  it  is  imperative  that  standards  are  uniform  across  all 
DoD  information  systems.  The  DoD  has  accelerated  implementation  of  standards 
within  DoD  information  systems  through  new  and  revised  policy  initiatives. 

These  initiatives  include  the  DoD  Joint  Technical  Architecture  for  achieving 
DoD-wide  inter-system  interoperability  and  increased  integration  of  commercial 
technology  in  DoD  systems.  For  the  warfighters,  these  initiatives  will  provide 
seamless,  transparent  operation  of  airborne  reconnaissance  systems  and  other 
DoD  systems,  enabling  them  to  work  together  to  provide  higher  quality  support  at 
lower  cost. 
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1.3  Scope 

Guiding  and  controlling  the  acquisition  of  interoperable  C4I  systems  requires  the 
use  of  architectures,  reference  models,  and  standards.  The  use  of  these  tools  to 
understand  and  analyze  complex  systems  is  well  understood  and  used  throughout 
the  DoD.  The  CINCs,  Services,  and  Agencies  use  architectural  constructs  to 
support  a  variety  of  objectives,  such  as  visualizing  and  defining  operational  and 
technical  concepts,  identifying  requirements,  guiding  systems  development  and 
implementation,  and  improving  interoperability.  This  section  introduces  the 
reference  models  used  to  define  the  technical  architecture  for  airborne 
reconnaissance,  explains  the  relationship  of  the  ARITA  with  other  standards 
documents,  and  cites  the  criteria  for  selecting  standards. 

1.3.1  Architectures  Defined 

The  proliferation  of  “architectures”  within  the  DoD  C4I  and  information  systems 
communities  prompted  the  Office  of  the  Secretary  of  Defense  (OSD)  to  task  a 
Defense  Science  Board  study  in  1994,  which  resulted  in  the  Joint  Chiefs  of  Staff 
approving  formal  architectural  definitions.  These  definitions  have  been  adopted 
for  the  ARITA  and  are  described  below.  Figure  1-3  shows  the  relationship  among 
the  three  defined  architectures  and  how  the  ARITA  fits  into  the  overall  scheme. 

1.3.1. 1  Operational  Architecture 

An  Operational  Architecture  is  “a  description  (often  graphical)  of  the  operational 
elements,  assigned  tasks,  and  information  flows  required  to  support  the 
warfighter.  It  defines  the  type  of  information,  the  frequency  of  exchange,  and 
what  tasks  are  supported  by  these  information  exchanges.”  (C4ISR) 

1.3. 1.2  Systems  Architecture 

“The  systems  architecture  defines  the  physical  connection,  location  and 
identification  of  the  key  nodes,  circuits,  networks,  warfighting  platforms,  etc., 
associated  with  information  exchange  and  specifies  systems  performance 
parameters.  The  systems  architecture  is  constructed  to  satisfy  operational 
architecture  requirements  per  the  standards  defined  in  the  technical  architecture.” 
(C4ISR) 
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The  operational  architecture 
describes  missions,  functions, 
tasks,  and  information  requirements. 


Bttohs  Mission  Applications 

p^Data.LMis' Mass  Storage  . 


;  Architecture 


The  systems  architecture  describes 
physical  connections,  nodes, 
networks,  warfighting  platforms, 
performance  parameters,  etc. 


The  technical  architecture  gives  the 
“building  codes  and  zoning  laws”  - 
interface  and  interoperability 
standards,  information  technology, 
security,  etc. 


Figure  1-3:  Architectures  Defined 


1 .3. 1 .3  T echnical  Architecture 

A  Technical  Architecture  is  a  “minimal  set  of  rules  governing  the  arrangement, 
interaction,  and  interdependence  of  the  parts  or  elements  whose  purpose  is  to 
ensure  that  a  conferment  system  satisfies  a  specific  set  of  requirements.  It 
identifies  system  services,  interfaces,  standards,  and  their  relationships.  It 
provides  the  framework,  upon  which  engineering  specifications  can  be  derived, 
guiding  the  implementation  of  systems.”  (C4ISR) 

1.3.2  Dual  Reference  Models 

“Architectures”  address  multiple  aspects  crossing  the  boundaries  of  operational, 
technical,  and  system  level  architectures  (as  defined  above).  The  ARITA  focuses 
on  the  technical  architecture  level,  and  it  specifically  identifies  only  those 
standards  that  have  a  direct  bearing  on  airborne  reconnaissance  systems. 
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In  order  to  achieve  the  desired  focus,  the  ARITA  uses  two  reference  models:  a 
functional  reference  model  (FRM)  and  a  technical  reference  model  (TRM).  These 
complementary  frameworks  (or  perspectives)  are  used  to  present  and  discuss  the 
technology  and  information  standards  selected  for  airborne  reconnaissance 
systems. 

The  FRM,  described  in  Section  3,  depicts  the  generic,  functional  makeup  of 
airborne  reconnaissance  systems  and  shows  how  the  various  functions  are 
interrelated.  It  is  particularly  well  suited  for  showing  which  specific  technology 
standards  apply  to  each  functional  area. 

The  TRM,  described  in  Section  4,  reflects  the  Technical  Architecture  Framework 
for  Information  Management  (TAFIM)  Volume  2,  Version  3  which  focuses  on 
information  technology  (IT)  standards  that  apply  to  specific  parts  of  the  FRM 
(e.g.,  the  operator-oriented  processing  functions).  It  is  well  suited  for  showing 
which  IT  standards  have  been  selected  for  airborne  reconnaissance  systems  and 
depicting  how  the  standards  relate  to  each  other. 

1.3.3  Basis  for  the  ARITA 

The  ultimate  objective  for  any  technical  architecture  is  to  influence  the  design  and 
implementation  of  actual  systems  to  improve  their  interoperability  and  enable 
incremental  migration  through  technology  insertion.  No  developer  can  completely 
predict  future  requirements  for  interoperability  among  multiple,  complex  systems 
given  the  rapid  advancement  of  technology  and  changing/unpredictable  military 
operations.  The  standards-based  framework  defined  by  a  technical  architecture 
facilitates  construction  of  new  system-to-system  interfaces  when  needed  (or 
envisioned)  with  lower  costs,  faster  implementation,  and  lower  technical  risk  than 
would  otherwise  be  incurred.  Equally  important,  the  standards-based  framework 
also  enables  insertion  of  advanced  technology  into  legacy  systems  with  lower 
costs,  faster  implementation,  and  lower  technical  risk  than  would  otherwise  be 
incurred.  By  enabling  this  flexibility  -  changing  interconnections  and  inserting 
advanced  technology  when  needed  -  a  technical  architecture  serves  to  facilitate 
“incremental  migration”  whereby  actual  systems  can  provide  increasing  military 
worth  while  adapting  to  keep  pace  with  evolving  warfighter  operational 
requirements. 

The  basis  for  the  ARITA  is  depicted  in  Figure  1-4.  It  focuses  on  the  specific  needs 
of  an  airborne  reconnaissance  architecture,  but  it  also  ties-in  to  the  various  DoD, 
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CINC,  Service,  and  Agency  architectures  to  ensure  the  best  possible  ISR  support 
for  the  warfighters. 


November  1993  -  DARO  Standup 
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DARO  Technology  & 
Program  Plan  Documents 


•Platforms/Sensor  Integration 
•Sensors 

•Oatalinks  &  Relays 
•Ground/Surface  Systems 
•C4I  Integration 


•Collection  Management 
•Mission  Planning 
•Mission  Control 


2010  Objective  Architecture 

> rivers ”  | 

v-T-  ..  j 


‘Architecture  Drivers” 


Lower  Life  Cycle  Costs  I 


Incremental  Migration  |  Interoperability 


Figure  1-4:  Basis  for  the  ARITA 


1.3.4  Relationships  of  ARITA  and  Other  Standards  Documents 

As  depicted  in  Figure  1-5,  the  ARITA  is  a  DoD-level  standards  document.  It 
complements  the  Defense  Information  Infrastructure  Common  Operating 
Environment  (DII  COE)  and  DoD  Joint  Technical  Architecture  (JTA)  which 
define  overall  standards  for  DoD  C4I  systems.  That  is,  the  ARITA  adds  standards 
required  for  an  airborne  reconnaissance  “domain.”  The  DII  COE,  JTA,  and 
ARITA  all  follow  the  DoD  Technical  Architecture  Framework  for  Information 
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Management  (TAFIM)  and  other  guidance  provided  by  the  Open  Systems  Joint 
Task  Force  (OS-JTF). 

Discipline-specific  standards  handbooks  provide  detailed,  implementation  level, 
standards  guidance  for  specific  interrelated  systems.  In  essence,  these  handbooks 
combine  the  DoD  level  technical  architecture  standards  with:  (1)  program-specific 
acquisition  guidance  such  as  master  migration  plans  and  common  development 
responsibilities;  and  (2)  other  DoD-level  standards  and  guidelines  developed 
specifically  for  SIGINT,  IMINT,  and  MASINT  communities.  There  are  currently 
two  standards  handbooks  governing  airborne  reconnaissance  systems:  the  Joint 
Airborne  SIGINT  Architecture  (JASA)  Standards  Handbook  and  the  Common 
Imagery  Ground/Surface  System  (CIGSS)  Acquisition  Standards  Handbook. 

These  standards  handbooks  were  written  by  the  developers  and  provide  the  most 
specific  guidance  for  implementing  interrelated  systems  (e.g.,  the  joint  SIGINT 
and  common  imagery  umbrella  programs  shown  in  the  diagram). 


DoD  Level  Technical  DoD  Level  Technical  Architecture  Discipline-Specific  Specific  Program 

Architecture  Framework  &  Common  Infrastructure  Standards  Handbooks  Development  and 


Figure  1-5:  Relationships  of  ARITA  and  Other  Standards  Documents 
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1.3.5  Criteria  for  Selecting  Standards 

The  selection  criteria  used  in  developing  the  ARITA  generally  focused  on 
identifying  standards  and  guidelines  determined  to  be  critical  for  interoperability, 
implementable,  and  used  commercially  or  widely  used  throughout  the  DoD  (in 
cases  where  commercial  standards  are  not  available).  As  with  the  DoD’s  recent 
initiative  to  define  the  Joint  Technical  Architecture  (see  Section  2.1.4),  the 
standards  selected  for  the  ARITA  should  meet  all  of  the  following  criteria: 

•  Interoperability  and/or  Business  Case  —  They  ensure  joint 
Service/ Agency  information  exchange  and  support  joint  (and 
potentially  combined)  C4I  operations,  and/or  there  is  strong  economic 
justifications  that  the  absence  of  a  mandated  standard  will  result  in 
duplicative  and  increased  life-cycle  costs. 

•  Maturity  —  They  are  technically  mature  and  stable. 

•  Implementability  —  They  are  technically  implementable. 

•  Public  —  They  are  publicly  available  (e.g.,  open  systems  standards). 

•  Consistent  with  Authoritative  Sources  —  They  are  consistent  with  law, 
regulation,  policy,  and  guidance  documents. 

Standards  that  are  commercially  supported  in  the  marketplace  with  validated 
implementations  available  in  multiple  vendors  mainstream  commercial  products 
take  precedence.  Publicly  held  standards  are  generally  preferred.  International, 
national,  and  industry  standards  are  preferred  over  military  or  other  government 
standards. 

The  ARITA  includes  document  and  selected  technology  standards.  Document 
standards  include  commercial,  international,  national,  federal,  military,  NATO, 
and  other  government  standards.  Selected  technology  standards  identify  critical 
elements  of  the  ARITA  deemed  essential  to  achieve  the  goals  described  in 
Section  1.1.  Together,  the  selected  standards  provide  descriptions  of  the 
engineering  and  design  criteria  and  specific  technical  requirements  that  must  be 
satisfied  by  airborne  reconnaissance  systems. 
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1.4  Document  Organization 

The  ARITA  consists  of  five  sections.  This  section  is  the  introduction  and 
overview.  The  next  four  sections  are: 

Section  2  Associated  Technical  Architectures  -  Identifies  the  principal  sources 
from  which  standards  were  selected  and  tailored  for  the  ARITA. 

Section  3  Airborne  Reconnaissance  Functional  Reference  Model  and  Selected 
Technology  Standards  -  Describes  the  FRM  and  identifies  technology 
selected  for  specific  functional  areas  in  the  ARITA. 

Section  4  Airborne  Reconnaissance  Technical  Reference  Model  and  Information 
Technology  Standards  -  Describes  the  TRM  and  identifies  information 
technology  (IT)  standards  selected  for  specific  IT  areas  in  the  ARITA. 

Section  5  Follow-On  ARITA  Activities  -  Identifies  the  key  follow-on  activities 
required  for  further  development  of  the  ARITA. 

1.5  What’s  New  in  this  Version 

This  is  the  first  release  of  the  ARITA  document.  This  section  will  summarize  the 
changes  made  in  subsequent  revisions. 

1.6  Configuration  Management 

This  document  is  under  configuration  control  of  the  ARITA  Working  Group, 
which  meets  periodically  (currently  monthly)  to  review  proposed  changes  to  the 
ARITA.  Please  send  all  comments  to  the  ARITA  secretariat,  C/O  MITRE 
Corporation,  Mail  Stop  Z030,  1820  Dolley  Madison  Blvd.,  McLean,  VA  22102- 
3481. 
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2.  Associated  Technical  Architectures 


This  section  provides  an  overview  of  the  principal  sources  from  which  standards 
were  selected  and  tailored  for  the  ARITA.  The  ARITA  synthesizes  across  those 
architectures,  identified  in  the  following  figure,  and  tailors  them  to  reflect  the 
needs  of  airborne  reconnaissance  systems.  In  general,  the  ARITA  adopts 
standards  already  mandated  by  the  DoD,  Services,  and  intelligence  community 
organizations  (e.g.,  CIO,  NSA)  to  serve  the  needs  of  the  airborne  reconnaissance 
acquisition  community.  In  addition,  future  versions  of  the  ARITA  will  identify 
follow-on  standards  initiatives  to  address  standardization  areas  that  are  critical  for 
airborne  reconnaissance  but  are  not  being  addressed  in  other  forums. 


DoD  Level  Technical  Architectures 


Technical  Architecture 
Framework  for  Information 
Management  (TAFIM) 


Defense  Information 
Infrastructure  (Dll)  Common 
Operating  Environment  (COE) 


DoD  Joint  Technical 
Architecture  (JTA) 


Army  Technical 
Architecture  (ATA) 


Discipline  Specific  Technical  Architectures 


Common  Imagery 
Ground/Surface  System 
(CIGSS) 


Joint  Airborne  SIGINT 
Architecture  (JASA) 


United  States  Imagery 
System  (USIS)  Standards  & 
Guidelines 


Collection  Management  and  Mission  Planning  System  Architectures 


Air  Force  Mission  Support 
System  (AFMSS) 


Joint  Collection  Management 
Tool  (JCMT) 


Tactical  Aviation  Mission 
Planning  System  (TAMPS) 


Imagery  Requirements 
Management  System  (RMS) 


DARO  Airborne 
Reconnaissance  Information 
Technical  Architecture  (ARITA) 


Figure  2-1:  Associated  Architectures 
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2.1  DoD  Level  Technical  Architectures 


2.1.1  Technical  Architecture  Framework  for  Information  Management 

The  Technical  Architecture  Framework  for  Information  Management  (TAFIM) 
provides  a  technical  architecture  definition  that  documents  the  services,  standards, 
design  concepts,  components,  and  configurations  used  to  guide  the  development 
of  other  technical  architectures.  The  underlying  premise  of  the  TAFIM  is 
implementation  of  an  open  systems  environment  for  information  systems.  This 
environment  allows  information  systems  to  be  developed,  operated,  and 
maintained  independent  of  applications  or  proprietary  vendor  products.  Open 
systems  are  characterized  by  their  use  of  standards  to  define  services,  interfaces, 
and  formats.  The  TAFIM  uses  international,  national  and  federal  standards,  which 
are  adopted  by  industry,  and  standards  agreed  to  by  the  U.S.  and  it’s  allies,  as  well 
as  selected  DoD  standards.  By  implementing  well-defined,  widely-known  and 
consensus-based  standards,  the  DARO  can  leverage  the  industry  investments  in 
the  commercial  market  and  assure  a  migration  path  into  the  future. 

2.1.2  Defense  Information  Infrastructure  Common  Operating  Environment 

The  Defense  Information  Infrastructure  (DII)  Common  Operating  Environment 
(COE)  describes  the  requirements  for  building  and  integrating  C4I  systems  for  the 
warfighters.  It  represents  the  basis  for  end-user  warfighter  systems  that 
reconnaissance  assets  support.  This  makes  the  DII  COE  a  very  important 
technical  source  for  developing  the  ARITA. 

The  DII  COE  is  a  “plug  and  play”  open  software  architecture  designed  around  a 
client/server  model.  It  provides  implementation  details  that  describe,  from  a 
software  development  perspective,  the  following: 

•  The  COE  approach  to  software  reuse, 

•  The  COE  runtime  execution  environment, 

•  The  definition  and  requirements  for  achieving  COE  compliance, 

•  The  process  for  automated  software  integration,  and 

•  The  process  for  electronically  submitting/retrieving  software 
components  to/from  the  COE  software  repository. 
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The  DII  COE  concept  is  best  described  as  an  architecture  that  is  fully  compliant 
with  the  TAFIM,  an  approach  for  building  interoperable  systems,  a  collection  of 
reusable  software  components,  a  software  infrastructure  for  supporting  mission 
area  applications,  and  a  set  of  guidelines  and  standards.  The  guidelines  and 
standards  specify  how  to  reuse  existing  software,  and  how  to  properly  build  new 
software  so  that  integration  is  seamless  and  automated. 

Two  systems  presently  use  the  DII  COE:  the  Global  Command  and  Control 
System  (GCCS),  and  the  Global  Combat  Support  System  (GCSS).  Both  use  the 
same  infrastructure  and  integration  approach,  and  the  same  COE  components  for 
functions  that  are  common  between  the  two  systems.  GCCS  is  a  C4I  system  with 
two  main  objectives:  the  near-term  replacement  of  the  World-Wide  Military 
Command  and  Control  System  (WWMCCS)  and  the  implementation  of  the  C*I 
For  the  Warrior  concept.  GCCS  is  already  fielded  at  a  number  of  operational 
CINCs.  GCSS  is  presently  under  development  and  is  targeted  for  the  warfighting 
support  functions  (logistics,  transportation,  etc.)  to  provide  a  system  that  is  fully 
interoperable  with  the  warfighter  C4I  system. 

2.1.3  Army  Technical  Architecture 

The  Army  Technical  Architecture  (ATA)  was  developed  by  the  Army  Staff, 

Army  Systems  Engineering  Office,  Army  Science  Board,  MACOMs,  and 
PEOs/PMs  to  support  the  Army  Enterprise  Strategy.  The  ATA  is  based  on  the 
TAFIM,  DoD  Directive  8320  series  governing  data  standardization,  and  the 
Army’s  initiatives  for  streamlining  the  acquisition  process.  It  mandates  the  use  of 
the  DII  COE  for  software  development,  the  use  of  specific  network  protocols  and 
message  formats  for  data  transport,  the  use  of  the  Defense  Data  Dictionary 
System  for  data  management,  and  the  use  of  IDEF  for  information  modeling.  It 
also  establishes  human-computer  interface  standards  and  delineates  standards  for 
information  security.  The  ATA  capitalizes  on  the  substantial  investment 
commercial  industry  has  made  in  information  technologies. 

2.1.4  DoD  Joint  Technical  Architecture 

DISA  is  leading  the  creation  of  the  Joint  Technical  Architecture  (JTA)  with  strong 
participation  from  the  Services,  Agencies,  and  (recently)  the  DARO.  The  JTA 
mandates  certain  “rules”  to  be  used  across  DoD  to  provide  specific  services  and 
interfaces  in  systems  being  procured  today.  All  standards  mandated  are  required 


Page  15 

DRAFT 


DRAFT 


for  interoperability  (unless  there  is  a  strong  business  case  against  it);  must  be 
mature,  technically  implementable,  and  publicly  available;  and  must  be  consistent 
with  authoritative  sources.  Commercial  product  availability  is  a  very  high  priority. 
The  scope  is  focused  on  C4I  interoperability  for  the  warfighter,  and  later  versions 
will  address  other  domains  (including  the  sustaining  base,  airborne 
reconnaissance,  and  weapon  systems). 

2.2  Discipline  Specific  Technical  Architectures 

There  are  currently  three  on-going  efforts  for  developing  discipline-specific 
technical  architectures:  (1)  Joint  Airborne  SIGINT  Architecture,  (2)  Common 
Imagery  Ground/Surface  System  Architecture,  and  (3)  United  States  Imagery 
System  Standards  and  Guidelines.  These  are  discussed  in  the  following 
subsections. 

2.2.1  Joint  Airborne  SIGINT  Architecture 

The  Joint  Airborne  SIGINT  Architecture  (JASA)  is  the  DoD’s  plan  for  meeting 
the  warfighter’s  2010  airborne  SIGINT  requirements  and  beyond.  The 
fundamental  philosophy  behind  JASA  is  to  leverage  the  digital  signal  processor 
(DSP)  technology  investment  of  commercial  industry  to  counter  the  ever  growing 
population  of  varied  radio  frequency  (RF)  signals,  reflecting  a  variety  of 
modulation  schemes  and  signal  multiplexing  structures.  By  digitizing  the  signal 
early  in  the  sensor  system,  common  hardware  processing  can  be  used  that  is 
independent  of  signal  type,  reducing  the  need  for  signal  specific  specialized 
hardware.  This  approach  to  signal  processing  increases  the  flexibility  and  overall 
capacity  of  the  SIGINT  system,  which  must  rapidly  respond  to  the  explosion  of 
digital  signals  in  the  environment.  Key  characteristics  of  JASA  are  that  it  will: 

•  Be  an  open  architecture 

•  Facilitate  digitization  close  to  the  RF  front-end  with  a  few 
standardized  intermediate  frequencies 

•  Incorporate  a  high  bandwidth  digital  local  area  network  onto  which 
both  general  and  specific  processors  can  be  connected 

•  Have  interface  standards  to  allow  for  connectivity  between  various 
hardware  implementations 

•  Maximize  the  use  of  commercial-off-the-shelf  (COTS)  technology 
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The  initial  version  of  the  JASA  functional  architecture  was  approved  by  the 
DARSC  and  published  in  June  1995.  The  airborne  reconnaissance  functional 
reference  model  described  in  Section  3  of  this  document  is  the  JASA  model  with 
adaptations  needed  for  the  overall  multi-discipline  ARITA. 

Version  1.0  of  the  JASA  Standards  Handbook  developed  by  the  JASA  Standards 
Working  Group  was  published  in  July  1996.  Standards  identified  in  that  document 
have  been  incorporated  in  the  ARITA. 

2.2.2  Common  Imagery  Ground/Surface  System  Architecture 

The  first  version  of  the  Common  Imagery  Ground/Surface  System  (CIGSS) 
Acquisition  Standards  Handbook  was  published  in  June  1995.  Standards  from  that 
document  have  been  incorporated  in  ARITA.  The  CIGSS  architecture  is  depicted 
in  Figure  2-2. 

The  CIGSS  concept  has  been  approved  by  the  JROC  and  is  fully  supported  by  the 
Services.  It  is  not  a  system  in  the  traditional  sense;  instead,  CIGSS  is  an  umbrella 
program  which  defines  interoperability,  performance,  and  commonality 
requirements  and  standards  for  DoD  ground/surface  based  imagery  processing 
and  exploitation  systems.  It  consolidates  the  following  systems  into  a  single 
DARP  project: 

•  The  Joint  Service  Image  Processing  System  (JSIPS)  program  - 
including  Navy,  Air  Force,  and  Marine  Corps 

•  The  Army’s  Enhanced  Tactical  Radar  Correlator  (ETRAC) 

•  The  Army’s  Modernized  Imagery  Exploitation  System  (MIES) 

•  The  imagery  parts  of  the  Air  Force’s  Contingency  Airborne 
Reconnaissance  System  (CARS) 

•  The  Marine  Corps’  Tactical  Exploitation  Group  (TEG)  programs 

•  The  Korean  Combined  Operational  Intelligence  Center  (KCOIC) 
imagery  systems 

Some  of  the  on-going  CIGSS  projects  include  revising  the  CIGSS  Acquisition 
Standards  Handbook,  development  of  a  Common  Imagery  Processor,  and 
interfacing  CIGSS  compliant  systems  with  the  following  imagery  community 
systems: 
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•  The  Image  Exploitation  Support  System  (IESS) 

•  The  Image  Product  Library  and  (IPL) 

•  The  Requirements  Management  System  (RMS) 

•  The  Joint  Collection  Management  Tool  (JCMT) 

•  The  Defense  Dissemination  System  (DDS) 


Future  efforts  will  include  interfacing  with  the  Medium  Altitude  Endurance 
(MAE)  and  High  Altitude  Endurance  (HAE)  UAVs  and  developing  common 
mission  planning  and  mission  control  functions. 


Mission  Planning 
and  Sensor  Control 


Commercial 

Imagery 

Workstations 


wa  tan.— Mia. 


CIGSS  Elements 


JSIPS 


Figure  2-2:  Common  Imagery  Ground/Surface  System 
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2.2.3  United  States  Imagery  System  Standards  and  Guidelines 

The  United  States  Imagery  System  (USIS)  Standards  and  Guidelines  focus  on 
information  technology  standards  specifically  pertaining  to  imagery  related 
application  programs  (i.e.,  software)  integrated  in  open  systems  computing 
environments.  The  standards  identified  in  the  USIS  Standards  and  Guidelines 
document  are  closely  tied  to  the  imagery-specific  services  identified  in  the  USIS 
Objective  Architecture  Definition  and  Evolution  document  and  the  USIS 
Technical  Architecture  Requirements.  The  USIS  imagery  standards  are  controlled 
by  the  Imagery  Standards  Management  Committee  (ISMC). 

The  scope  of  the  USIS  Standards  and  Guidelines  document  is  limited  to  imagery- 
specific  standards  that  ensure  interoperability  among  elements  of  the  USIS.  Other 
standards  that  would  apply  are  identified  in  higher  level  standards  documents, 
such  as  the  TAFIM,  or  peer  level  profiles. 

Standards  cited  in  Version  1  of  the  USIS  Standards  and  Guidelines  document, 
dated  13  October  1995,  are  incorporated  in  this  ARITA.  Other  sources  include  the 
CIGSS  (see  Section  2.2.2)  and  information  obtained  from  various  Central 
Imagery  Office  CIO-sponsored  imagery  standards  working  groups  (e.g.,  video, 
common  interoperable  imagery  facilities,  etc.). 

2.3  Collection  Management  and  Mission  Planning  System  Architectures 

The  ARITA  would  be  unacceptably  incomplete  if  it  did  not  tie-in  with  an 
effective  architecture  for  collection  management  and  mission  planning.  However, 
such  an  architecture  has  not  been  defined  by  the  DoD  or  Services.  Therefore, 
functions  and  standards  were  derived  for  the  ARITA  from  an  assessment  of  four 
key  systems  and  their  planned  migrations: 

•  The  Joint  Collection  Management  Tool  (JCMT); 

•  The  imagery  community’s  Requirements  Management  System  (RMS); 

•  The  Air  Force  Mission  Support  System  (AFMSS);  and 

•  The  Navy’s  Tactical  Aviation  Mission  Planning  System  (TAMPS). 

More  detail  on  these  systems  is  provided  in  Section  3.8,  System  Planning  and 
Control  Functions. 
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2.3.1  Collection  Management  Systems 

Routine  tasking  to  an  operational  collection  asset  (either  airborne  or  national) 
normally  flows  via  an  up-echelon  Collection  Management  Authority  (CMA).  The 
process  can  include  provisions  to  allow  ad  hoc  tasking  to  be  generated  directly  by 
a  supported  task  force  or  task  force  component.  The  collection  management 
systems  provide  functions  that  support  the  CMA  in  prioritizing  collection  requests 
(which  could  be  received  from  numerous  users),  generating  specific  tasking  for 
the  designated  collection  asset(s),  and  tracking  the  status  of  that  collection  tasking 
and  subsequent  ISR  reporting. 

There  are  two  specific  collection  management  systems  that  will  interact  with 
airborne  reconnaissance  systems  in  the  future  (either  directly  or  indirectly). 

The  Joint  Collection  Management  Tool  (JCMT)  is  the  migration  system 
designated  by  the  DoD  to  be  used  for  all  DoD  all-source  collection  management 
functions  (i.e.,  legacy  systems  will  be  phased  out  as  JCMT  supersedes  them).  As 
such,  it  will  combine  IMINT,  SIGINT,  MASINT,  and  HUMINT  tasking. 

However,  MASINT  requirements  for  collection  management  tasking  are  not 
defined  at  this  time. 

The  Requirements  Management  System  (RMS)  is  the  migration  system 
designated  by  the  DoD  to  be  used  for  all  DoD  imagery  collection  management 
functions.  An  RMS  aircraft  tasking  study  has  been  recently  completed  which 
defines  a  conceptual  CONOPS  and  technical  requirements  for  interfacing  with 
imagery  ground  stations,  AFMSS,  and  TAMPS.  However,  this  has  not  been 
completely  reflected  in  the  ARITA  since  the  results  have  not  yet  been  fully 
coordinated/approved  nor  has  an  implementation  plan  been  developed.  Mission 
Planning  Systems 

2.3.2  Mission  Planning  Systems 

A  multitude  of  mission  planning  systems  exist  today.  Many  of  these  are  special 
applications  that  were  designed  for  specific  aircraft  and  operate  on  specific 
hardware  suites.  There  are  formal,  programmatic  efforts  underway  to  consolidate 
these  into  several  generic  systems,  two  of  which  were  picked  as  representative 
systems  for  purposes  of  developing  the  ARITA:  The  Navy’s  TAMPS  and  the  Air 
Force’s  AFMSS.  Note  that  other  specific  mission  planning  systems  have  been 
consolidated  into  these  two  programs.  TAMPS  consists  of  a  core  and  a  number  of 
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mission  planning  modules  for  specific  Navy,  Marine  Corps,  and  Coast  Guard 
aircraft  and  weapons.  AFMSS  contains  a  core  and  a  number  of  avionics/weapons/ 
electronics  (AWE)  modules  for  specific  Air  Force,  Army,  and  US  Special 
Operations  Command  aircraft  and  weapons.  Long-term  plans  call  for  combining 
these  into  one  DoD-wide  mission  planning  system. 

Both  TAMPS  and  AFMSS  have  adopted  the  same  general  architectural  design 
and  acquisition  approach:  (1)  common,  centrally  procured  hardware;  (2)  common, 
centrally  procured  and  managed  software;  and  (3)  aircraft-specific  software 
modules  and  data  transfer  devices  that  are  (generally)  procured  and  managed  by 
aircraft  program  managers.  For  example,  both  the  AFMSS  system  and  the 
TAMPS  system  consist  of  common,  core  software  sets  and  specific  AWE 
(avionics/weapons/electronics)  modules  for  supported  aircraft. 

Basic,  core  functions  provided  by  both  mission  planning  systems  include: 

•  Integrate  and  manage  critical  information  including  operations, 
weather,  intelligence,  threat  analysis,  maps  and  charts,  digital  terrain 
elevation  data  (DTED),  imagery,  and  command/control  information; 

•  Produce  maps  and/or  strip  charts,  flight  plans  and  knee-board  cards, 
radar  predictions,  imagery,  and  post-mission  reports;  and 

•  Program  the  data  transfer  device  which  automatically  initializes  the 
aircraft  avionics  for  the  specific  mission  planned  on  the  system. 

While  both  the  TAMPS  and  AFMSS  programs  show  plans  to  provide  mission 
planning  capabilities  for  reconnaissance  platforms  (such  as  the  U-2,  UAVs,  RC- 
135,  EP-3,  F/A-18  and  others),  the  plans  are  generally  for  platform  and  navigation 
planning  only  (e.g.,  flight  path,  threat  avoidance,  take-off  and  landing 
calculations,  fuel  consumption,  etc.).  Mission  planning  modules  for  the 
reconnaissance  sensor  system  payloads  and  communications  system  planning  are 
currently  not  in  the  baseline. 
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3.  Airborne  Reconnaissance  Functional  Reference  Model  and 
Selected  Technology  Standards 

The  airborne  reconnaissance  functional  reference  model  (FRM)  provides  a 
common  framework  for  defining  the  scope  and  functional  makeup  of  airborne 
reconnaissance  systems.  The  FRM  is  critical  for  selecting  standards  and 
effectively  depicting  where  they  must  be  applied  in  the  overall  framework.  The 
FRM  is  based  on  the  functional  model  developed  by  the  Joint  Airborne  SIGINT 
Architecture  (JASA)  Working  Group  and  approved  by  the  Defense  Airborne 
Reconnaissance  Steering  Committee  (DARSC).  The  FRM  incorporates  additional 
functions  found  in  IMINT  and  MASINT  systems  required  to  satisfy  warfighter 
requirements,  more  explicit  mission  planning  and  control  functions,  and  expanded 
functions  for  integrating  airborne  reconnaissance  with  warfighter  and  other  C4I 
systems  (e.g.,  command  and  control  systems,  air  tasking,  and  collection 
management). 

3.1  FRM  Overview 

The  airborne  reconnaissance  FRM  shown  in  Figure  3-1  breaks  out  the  overall 
functional  components  into  seven  distinct  areas: 

•  Front-end  processing  functions; 

•  Navigation,  timing,  and  ancillary  data; 

•  Networking  functions; 

•  High  performance  processing  functions; 

•  Operator-oriented  processing  functions; 

•  Reporting  and  connectivity  functions;  and 

•  System  planning  and  control  functions. 

There  is  a  high  degree  of  commonality  in  the  Operator-oriented  and  Reporting  & 
connectivity  functions  which  suggests  these  areas  are  the  most  important  for 
applying  standards. 


Page  23 

DRAFT 


DRAFT 


Four  key  adaptations  were  added  to  the  JASA  functional  model  to  accurately 
reflect  and  integrate  functions  for  the  other  “INTs.”  The  overall  airborne  . 
reconnaissance  functional  reference  model  consists  of: 

•  Different  front-ends  for  SIGINT,  IMINT,  and  MASINT ; 

•  Product  libraries  for  audio,  imagery,  MASINT,  and  SIGINT  data; 

•  Multimedia  network  sized  for  data,  digital  audio,  digital  video, 
imagery,  MASINT,  and  SIGINT  data  rates;  and 

•  Integrated  system  planning  and  control  functions. 

The  airborne  reconnaissance  FRM  is  a  generic  model  intended  to  show  only 
functional  flow;  it  does  not  depict  actual  implementations  of  airborne 
reconnaissance  systems.  The  generic  model  is  intended  to  encompass  all  aspects 
of  an  airborne  reconnaissance  architecture  that  will  meet  the  needs  of  manned 
aircraft  and  Unmanned  Aerial  Vehicles  (UAVs)  as  well  as  their  sensors  and 
associated  ground/surface  systems.  The  FRM  provides  the  functional  framework 
for  achieving  the  goals  and  objectives  of  the  ARITA  cited  in  Section  1.1,  Purpose. 

A  description  of  each  functional  block  in  the  FRM  is  given  in  the  following 
subsections  together  with  discussions  of  applicable  technology  standards.  This 
includes  identification  of  those  standards  selected  for  airborne  reconnaissance 
systems  (i.e.,  mandated),  and  references  to  technologies  which  are  not  yet  mature 
enough  to  select  as  standards  but  show  promise  for  resolving  key  technical 
architecture  issues. 

Based  on  the  technology  standards  identified  in  this  section  an  overall  roll-up  of 
the  selected  and  emerging  information  technology  standards  is  provided  in 
Section  3.9,  Summary  of  Technology  Standards. 
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3.2  Front-End  Processing  Functions 

In  general,  the  front-end  processing  functions  encompass  all  of  the  mechanics 
associated  with  integration  of  SIGINT,  IMINT,  and  MASINT  sensors  into  the 
various  platforms,  sensor  data  capture  and  recording,  special  pre-processing,  and 
interfacing  the  front-end  functions  with  the  rest  of  the  FRM.  Due  to  the  nature  of 
the  physical  phenomenon  being  exploited,  the  specific  functions  of  the  front-end 
sensors  are  different.  The  common  front-end  functions  are  discussed  in  the  next 
subsection  followed  by  discipline-specific  functions  for  SIGINT,  IMINT,  and 
MASINT. 

3.2.1  Common  Front-End  Functions 

The  following  functional  elements  are  common  across  the  three  front-end 
functional  areas  (color  coded  green):  Sensor/Platform  Integration  Mechanics, 
Sensor  Control  Functions,  Special  Pre-Processing  Functions,  and  Mission 
Recorders. 

3.2.1.1  Sensor/Platform  Integration  Mechanics 

Standards  for  this  functional  area  are: 

•  Prime  Power:  MIL-STD-704E 

The  integration  of  the  sensor  into  an  airframe  is  a  complex  task.  In  addition  to  the 
classic  interface  specifications  of  size,  weight,  and  power;  airframe  integration 
must  include  balance,  pressurization,  cooling,  and  unique  mounting 
configurations.  Dynamic  operational  conditions  that  must  be  addressed  are 
vibration,  shock,  torque,  pressure  and  atmospheric  changes.  Integration  of  any 
sensor  into  an  airborne  platform  covers  several  areas  and  requires  a  total  system 
analysis. 

In  the  case  of  a  SIGINT  system,  the  platform  antenna  (or  antenna  arrays) 
frequency  range,  sensitivity,  directional  patterns,  and  calibration  must  match  the 
SIGINT  sensor  capability.  Although  this  matching  is  done  through  engineering 
design  processes  it  is  not  sufficient  to  ensure  achievement  of  performance 
specifications  when  installed  on  a  physical  airframe  and  connected  with  prime 
(Group  B)  SIGINT  receiving  equipment.  Additional  modeling  may  be 'needed  in 
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such  cases.  Thus  anechoic  chamber  work  on  platform  scale  models  is  standard 
practice  to  accommodate  anomalies  in  performance  that  occur  in  interferometric 
DF.  These  anomalies  are  typically  caused  by  the  antenna  elements  interacting 
with  the  airframe  causing  resonance  at  some  frequencies.  The  resonant 
frequencies  effectively  cause  signal  nulls  or  signal  drop-outs,  and  ambiguous  DF 
answers  can  be  adjusted  by  slightly  readjusting  antenna  locations  in  the  anechoic 
chamber  modeling  before  installing  them  on  the  airframe.  This  avoids  problems 
before  expensive  airframe  modifications  are  made.  The  addition  of  antenna  (or 
antenna  arrays)  requires  modification  of  existing  RF  distribution  to  match  RF 
feeds  from  new  antenna  elements  and  proper  RF  outputs  to  receivers,  tuners,  or 
converters. 

Imagery  sensors  are  typically  mounted  in  the  nose  of  the  airframe,  the  underside 
of  the  fuselage,  or  in  a  pod.  The  enclosure  covering  the  sensor  may  be  either  part 
of  the  airframe,  part  of  the  pod,  or  part  of  the  sensor  system.  The  sensors  are 
typically  enclosed  in  an  unpressurized  compartment  and  image  through  a  window. 
The  imaging  window  must  maintain  optical  quality  and  sustain  a  pressure 
differential  from  buffeting  winds.  If  the  sensor  is  in  a  pressurized  compartment, 
the  window  strength  becomes  even  more  important.  High  quality  sapphire 
windows  are  typically  used,  but  there  are  also  substitutes.  Sapphire  windows  are 
just  now  being  produced  in  sizes  large  enough  (12  inch)  to  be  used  for  high 
quality  electro-optical  sensors  with  large  apertures.  Infrared  and  multi-spectral 
sensors  have  the  most  severe  specifications  for  the  optical  window.  The  sensor 
enclosure  may  move  to  keep  the  window  centered  on  the  optical  axis.  Although 
this  increases  sensor  to  airframe  mounting  complexity,  it  is  not  practical  to  make 
the  windows  large  enough  to  cover  the  complete  sensor  field  of  view.  The 
windows  may  require  heating  or  cooling  to  eliminate  condensation  and  maintain 
performance.  Radar  systems  used  for  collecting  IMINT  are  enclosed  in  radomes 
that  typically  can  be  produced  as  uniformly  transparent,  and  they  do  not  have  to 
rotate  or  move  in  unison  with  antenna  movements. 

There  are  no  special  requirements  to  integrate  MASINT  sensors  which  are  the 
same  as  SIGINT  or  IMINT  sensors.  Other  MASINT  sensors  require  appropriate 
integration,  for  example,  MASINT  sensors  exposed  to  the  atmosphere  for  air 
sampling  purposes.  Future  MASINT  sensors  -  including  tunable  or  programmable 
sensors  -  may  be  pod  mounted  or  be  enclosed  as  part  of  the  airframe. 

The  only  standard  identified  for  sensor/platform  integration  is  for  Prime  Power: 
MIL-STD-704E. 
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3.2.1.2  Sensor  Control  Functions 

Standards  for  this  functional  area  are: 

•  None 

Commands  to  various  SIGINT,  IMINT,  and  MASINT  front-end  equipment  flow 
through  the  sensor  control  component  of  the  FRM.  In  actual  implementations, 
command  and  control  messages  may  flow  directly  to  equipment  through  either  the 
C2  network  or  the  high  speed  data  flow  network. 

There  are  no  standards  currently  identified  for  sensor  control  functions.  However, 
this  may  be  an  area  worthy  of  further  analysis.  A  standard  command  set  may  be 
an  effective  means  to  stimulate  design  and  marketing  of  competitive  equipment. 

A  simple  example  of  the  benefit  of  a  standard  command  set  is  seen  in  the 
common  modem  used  in  virtually  every  personal  computer  and  office  workstation 
-  they  all  use  the  basic  Hayes  command  set. 

3.2.1.3  Special  Pre-Processing  Functions 

Standards  for  this  functional  area  are: 

•  None 

The  FRM  allows  for  variations  of  special  pre-processors  to  coexist  in  the  system. 
The  variations  will  be  optimized  to  provide  specific  mission  functions,  but  will 
have  common  interfaces  for  timing,  to  include  both  coherency  and  absolute  time, 
and  for  command  and  control. 

The  FRM  provides  for  special  pre-processing  functions  that  either  (a)  cannot  be 
implemented  in  the  digital  domain,  or  (b)  are  optimized  by  analog  pre-processing. 
The  output  of  the  pre-processors  will  interface  to  the  high-speed  data  flow 
network  and,  if  applicable,  to  the  multimedia  network. 

Pre-processing  functions  are  performed  to  the  sensor  data  for  the  purposes  of 
enhancing  data  utilization.  Functions  may  include  analog-to-digital  conversion, 
data  compression,  and  data  formatting. 

Although  there  are  no  standards  for  special  pre-processing  functions,  standards 
should  be  developed  for  assuring  end-to-end  quality. 
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3.2.1.4  Mission  Recorders 

Standards  for  this  functional  area  are: 

IMINT  payloads: 

•  High  data  rate  digital  imagery: 

-  DCRSi  for  the  U-2  (ASARS-II  recorder) 

-  ANSI X3B5/94-024,  19  mm  helical  scan  digital  tape  (F/A-18 
ATARS) 

-  ANSIX3. 1 75-1990,  ID-1  digital  tape  (F/A-18  ATARS) 

•  Legacy  analog  video: 

—  VHS  and  Super-  VHS  for  recording  video 

-  Hi  8  mm  (e.g,  for  ARL  and  gun  cameras) 

•  Video  migration  to  digital: 

-  Preferred  implementation  is  Y/C  (component  analog)  video 
recorders  with  Society  of  Motion  Picture  and  Television 
Engineers  (SMPTE)  vertical  interval  time  code  VITC 
generators/readers  and  two  audio  tracks  (one  for  mission 
audio,  one  for  ancillary  data) 

-  Dual-capable  analog/SMPTE  259M  video  recorders  (to 
support  the  migration  from  analog  to  digital  video) 

•  Digital  video: 

—  SMPTE  259M-compliant  recorders  capable  of 259M  input  and 
output 


SIGINT  payloads: 

•  Hi  8  mm  (ARL  ESM  data) 

•  AN/USH-28,  28  track  tape  recorder  (RC-135) 

•  Optical  drive  for  archive  data  (RC-12) 

•  Magnetic  drive  for  temporary  data  (RC-12) 
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*  Digital  temporary  storage  recorder  (DTSR),  based  on  Winchester 
hard  disk  (Army  and  Air  Force  programs) 

Timing: 

*  IRIG-106-93,  Telemetry  Standards,  Analog  Digital  Adaptable  Input 
Output  Data  Format  Specification  Annex 

Mission  recorders  are  used  to  capture  the  raw,  pre-processed  sensor  data  together 
with  associated  navigation,  timing,  and  ancillary  data.  Additionally  a  computer 
controlled  interface  for  basic  recorder  functions  such  as  start,  stop,  shuttle,  fast 
forward,  and  rewind  is  included. 

In  conjunction  with  recording  the  raw  sensor  data,  timing  data  will  be  recorded 
(on  a  separate  track)  in  accordance  with  the  “IRIG-B”  (Inter-Range 
Implementation  Group)  standard:  IRIG-106-93,  Telemetry  Standards,  Analog 
Digital  Adaptable  Input  Output  Data  Format  Specification  Annex.  The  IRIG-B 
standard  was  written  specifically  for  magnetic  tape  storage,  but  it  is  applicable  to 
disk  storage  media  as  well. 

The  standards  cited  above  include  legacy  systems.  In  conjunction  with  migrating 
to  all  digital  systems,  mission  recorder  standards  will  be  reevaluated  to  emphasize 
digital  and  de-emphasize  analog. 

3.2.2  SIGINT  Front-End  Functions 

SIGINT  front-end  standards  are  concerned  primarily  with  functional  elements  that 
receive  and  process  radio  frequency  (RF):  from  low  frequency  (LF),  30  KHz  to 
300  KHz,  through  extra  high  frequency  (EHF),  30  GHz  to  300  GFIz,  received  by 
the  platform  antenna/antenna  arrays.  These  RF  antenna/antenna  array  types  may 
be  omni-directional,  directional,  beam-steered,  steered  dish,  interferometric,  or 
spinning  dish.  In  addition  to  the  common  front-end  functions,  the  SIGINT  front- 
end  functional  elements  include  the  RF  distribution,  low  and  high  band  tuners, 
set-on  receivers,  IF  distributing  IF  digitizer  and  sub-band  tuners,  digitizers  and 
channelizers.  Figure  3-2  displays  the  functional  elements  of  the  SIGINT  front- 
end.  Hardware  implementation  may  not  match  Figure  3-2:  SIGINT  Front-End 
FRM  (e.g.,  low/high  band  tuners,  IF  switching,  and  IF  digitization  functions  can 
be  combined  into  a  single  receiver  unit). 
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Figure  3-2:  SIGINT  Front-End  FRM 


3.2.2. 1  RF  Distribution 

Standards  for  this  functional  area  are: 

•  50  Ohm  fixed  impedance  coaxial  cable  in  agreement  with  EIA  RS-225, 
dated  1959 

RF  from  antenna  normally  flows  through  an  RF  distribution  function.  The  RF 
distribution  function  allows  for  appropriate  signal  flow  from  the  multitude  of 
platform  antenna  of  varying  types  and  frequency  coverage  and  provides  for  the 
conditioning  and  distribution  to  the  functional  receiver/tuner  elements. 

The  conditioning  component  of  the  RF  distribution  provides  for  the  requisite 
preselection  or  band  filtering  to  frequency  band-limit  incoming  antenna  paths 
from  potentially  interfering  signals  (both  off-board  and  on-board)  and 
preamplification  to  optimize  the  system-level  noise  while  providing  an  acceptable 
signal  saturation  level  (i.e.,  intercept  point).  Phase/gain  matching  of  multiple 
discrete  antenna  paths  for  interferometric  direction  finding  (DF)  is  also  a  function 
of  the  RF  distribution  conditioning. 

The  distribution  function  provides  appropriate  RF  switches,  RF  power  dividers  or 
coupler,  attenuators,  and  blanking  interface  to  facilitate  the  necessary  quantity  and 
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type  of  signal  paths  to  the  various  platform  SIGINT  receiver/tuners.  This  allows 
multiple  signal  paths  to  be  routed  or  selected  to  one  or  more  receiver  paths  for 
maximum  flexibility  and  to  reduce  the  number  of  dedicated  antennas  that 
otherwise  would  be  required  on  the  platform. 

Traditionally,  RF  from  antenna  has  been  distributed  to  tuners,  band  converters, 
and  receivers  through  50  Ohm  fixed  impedance  coaxial  cable  in  agreement  with 
Electronic  Industries  Association  (ELA)  RS-225,  dated  1959.  Replacement  of 
coax  with  fiber  optics  is  being  researched  for  ELINT  antenna  to  RF  distribution. 
Early  digitization  (analog  to  digital  (A/D)  conversion)  and  precise  time  tagging  of 
this  digital  data  are  essential  elements  of  this  architecture.  Properly  bandwidth- 
limited  RF  is  passed  on  to  ELINT  and  COMINT  tuners,  receivers,  or  band 
converters. 

3.2.2.2  Low  and  High  Band  Tuners 

Standards  for  this  functional  area  are: 

•  IF  center  frequencies  of  21.4  MHz,  70  MHz,  160  MHz,  1000  MHz,  and 
5000  MHz 

Highband  RF  covers  the  UHF  through  EHF  (300  MHz  to  300  GHz).  Low  band 
RF  covers  LF  through  UHF  (30  KHz  to  3  GHz).  The  LF,  UHF,  and  EHF 
designations  follow  the  Institute  for  Electrical  and  Electronic  Engineers  (IEEE) 
definitions.  However,  signal  densities  and  properties,  propagation  factors,  and 
semiconductor  physics  necessitate  different  basic  implementations.  Actual 
implementation  must  provide  seamless  processing  of  all  specified  signals  of 
interest.  The  frequency  coverage  and  number  of  channels  will  be  a  function  of  the 
individual  platform  and  mission  requirements. 

The  tuners  (several  types  are  required)  will  provide  preselection  of  a  portion  of 
the  RF  spectrum  and  convert  it  to  one  of  the  standard  intermediate  frequency  (IF) 
center  frequencies  of  21.4  MHz,  70  MHz,  160  MHz,  1000  MHz,  and  5000  MHz. 
The  tuner’s  technical  specifications  should  reflect  the  requirements  to  allow 
direction  finding,  time  difference  of  arrival,  differential  Doppler,  co-channel 
interference  reduction,  pulse  code  modulation,  etc.  The  IF  from  the  high  band 
tuners  may  feed  through  a  coaxial  based  (50  Ohm)  IF  distribution  into  the  RF 
distribution  function  to  allow  further  selection  and  processing  by  the  low  band 
tuners  and  assets  for  narrowband  signals.  The  IF  from  the  low  band  tuners  may 
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feed  into  the  high  band  IF  distribution  function  to  allow  further  selection  and 
processing  for  wideband  signals. 

3.2.2.3  Set-On  Receivers 

Standards  for  this  functional  area  are: 

•  None 

The  FRM  incorporates  provision  for  a  pool  of  set-on  receivers  to  enhance 
collection  based  on  a  platform’s  operational  mission.  These  receivers  would  be 
included  when  system  constraints  prohibit  contiguous  coverage,  when  additional 
throughput  is  required,  or  when  additional  coverage  of  specific  high  priority 
signals  is  to  be  provided.  The  set-on  receiver  outputs  may  be  digital  audio,  digital 
IF  (filtered),  or  analog  (pre-  or  post-  detected).  The  numbers,  types,  frequency 
range,  modulations,  and  outputs  of  these  receivers  will  be  determined  by  the 
individual  platform’s  requirements.  There  are  currently  no  formalized  standards 
for  set-on  receivers  and  conventional  practice  is  to  use  commercially  available 
equipment. 

3.2.2.4  IF  Distribution 

Standards  for  this  functional  area  are: 

•  None 

The  FRM  allows  for  multiple  IFs  to  exist  in  the  system.  The  IF  distribution 
function  accepts  the  various  inputs  from  the  tuners  and  receivers  and  routes  them 
to  the  outputs  via  the  C2I  network.  The  IF  switches  and  distribution  elements  must 
support  the  dynamic  range,  phase  noise,  linearity,  bandwidth,  isolation  and  other 
functional  specifications  required  of  their  collective  applications.  As  with  the  RF, 
IF  signals  are  also  distributed  through  50  Ohm  coaxial  cable. 

3.2.2.5  IF  Digitizer 

Standards  for  this  functional  area  are: 

•  None 
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The  IF  digitizer  accepts  the  output  of  the  tuners  and  IF  distribution,  and  performs 
the  analog  to  digital  (A/D)  conversion.  It  may  include  such  functions  as  down- 
conversion  and  signal  conditioning.  This  digital  output  is  connected  to  the  high¬ 
speed  data  flow  network.  The  digitizers  may  be  comprised  of  multiple-speed 
bandwidth  and  dynamic  range  converters  (reflecting  the  different  processing 
bandwidth  /  dynamic  range  tradeoffs  required  for  different  signals).  The  data  will 
include  a  precision  time  stamp  and  system  clock.  Precise  time-tagging  of  data  will 
take  place  at  the  point  of  digitization. 

3.2.2.6  Sub-Band  Tuners/Digitizers/Channelizers 

Standards  for  this  functional  area  are: 

•  None 

The  sub-band  tuners/digitizers/channelizers  accept  the  output  of  the  high  band 
tuners  and  IF  distribution  functions.  This  module  will  support:  automatic  and 
manual  search  of  signals  with  direction  finding  (antenna/array  dependent);  signal 
characterization;  sample  incoming  IF  energy;  and  measurement  of  phase  shift  of 
IF  energy.  These  functions  must  provide  high  performance  (e.g.,  sensitivity, 
dynamic  range,  interference  cancellation)  and  allow  for  reprogramming  (scan 
plans,  signal  parameters,  etc.).  Signal  data  will  be  provided  to  the  high-speed  data 
flow  network.  This  functional  block  must  accept  time  synchronization  and  system 
clock  and  also  time-tag  the  digitized  data  as  required. 

3.2.3  IMINT  Front-End  Functions 

As  shown  in  Figure  3-3,  IMINT  front-end  functions  are  divided  into  ten  major 
areas:  seven  types  of  image  acquisition  sensors,  sensor  control  functions,  special 
pre-processing  functions,  and  mission  recorders.  The  following  subsections 
describe  the  seven  types  of  image  acquisition  sensors  and  the  specific  technology 
standards  that  apply.  The  other  areas  are  discussed  in  Section  3.2.1. 
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Figure  3-3:  IMINT  Front-End  FRM 


3.2.3.1  Film  Cameras 

Standards  for  this  functional  area  are: 

•  None 

Film  cameras  typically  used  in  airborne  reconnaissance  systems  employ  advanced 
optics  (lenses  and/or  mirrors)  and  focusing  subsystems  to  capture  high  quality 
imagery  on  large-format  film.  Film  width  is  not  standardized,  but  ranges  from 
four-to-nine  inches  wide  depending  on  the  design  of  the  camera.  Lens  focal 
lengths  vary  from  25  inches  for  wide  area  coverage  to  almost  150  inches  for  high 
resolution  imaging  from  greater  distances. 

Film  cameras  are  being  phased  out  as  IMINT  systems  migrate  to  electronic/digital 
imaging  sensors  which  offer  superior  performance  and  image  processing 
capabilities. 

3.2.3.2  Electro-Optical  Sensors 

Standards  for  this  functional  area  are: 

•  None 
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Electro-optical  (EO)  sensors  are  essentially  the  same  as  traditional  film  cameras 
except  that  electronic  imaging  is  used  in  place  of  film.  EO  sensors  offer  higher 
quality  and  faster  response  to  warfighters  by  enabling  the  use  of  digital  image 
processing  technology,  direct  data  link  communications,  and  more  sophisticated 
storage  and  dissemination  capabilities. 

EO  sensors  typically  cover  the  panchromatic  (or  Pan)  part  of  the  spectrum  and  use 
digital  techniques  to  collect  image  data  (i.e.,  staring  arrays  and  linear  scanning 
arrays).  In  a  strict  sense  the  term  “panchromatic”  means  the  light  spectrum  that  is 
visible  to  the  human  eye.  In  practice  this  usually  applies  to  a  modified  spectrum  in 
which  the  EO  sensor  operates.  Typically,  Pan  EO  sensor  sensitivity  may  exclude 
some  of  the  blue  region  of  the  spectrum  and  may  include  some  near  infrared  (IR) 
wavelengths  of  the  spectrum.  The  blue  may  be  excluded  to  reduce  the  effects  of 
haze  in  long  range  viewing,  whereas  near  IR  penetrates  the  haze  better  than 
visible  wavelengths  and  provides  better  contrast  between  vegetation  and 
camouflage.  More  detail  on  IR  is  in  Section  3.23.3. 

Staring  array  sensors  use  a  two-dimensional  array  that  acquires  the  entire  frame  at 
a  single  instant,  just  like  a  handheld  film  camera.  These  sensors  are  capable  of 
taking  between  a  few  frames  a  second  to  a  frame  every  few  seconds.  Typical  focal 
plane  arrays  vary  from  between  500  to  2,000  detectors  on  each  side,  and  they  are 
usually  square.  The  images  formed  generally  have  the  same  number  of  pixels  as 
the  array  has  detectors.  These  sensors  need  to  be  physically  stabilized  to  keep 
each  detector  focused  on  the  same  target  for  the  duration  of  the  exposure  -  a 
platform/sensor  integration  consideration.  The  resulting  images  are  a  series  of  still 
frames. 

Linear  scanning  array  sensors  use  a  string  of  electronic  detectors  to  record  only 
one  line  of  the  image  at  a  time.  The  linear  array  is  typically  2,000  to  20,000 
detectors  wide.  This  determines  how  many  pixels  are  in  each  line  of  the  processed 
image.  An  image  is  formed  as  the  aircraft  and  sensor  motion  continuously  scans 
new  parts  of  the  scene.  The  resulting  image  formed  by  a  scanning  array  sensor  is  a 
continuously  moving,  or  waterfall  image.  Nothing  on  the  image  moves  as  in  a 
video  or  movie;  rather  the  scene  itself  is  continuously  moving  as  the  sensor  scans 
the  ground  given  the  motion  of  the  aircraft. 

Currently  there  are  no  formalized  standards  governing  the  design  of  EO  sensors, 
but  the  following  two  technical  attributes  tend  to  be  common  among  various 
sensor  designs: 
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•  Most  monochromatic  (greyscale)  sensors  produce  imagery  at  8  to  1 1 
bits  per  pixel.  Color  sensors  most  often  output  24  bits  per  pixel  (e.g., 
eight  bits  each  for  red,  blue,  and  green.) 

•  Asa  practical  limit  derived  from  the  Common  Data  Link,  most  EO 
sensors  output  data  at  rates  less  than  274  megabits  per  second.  This 
affects  design  trades  between  detector/spacing  (spatial  resolution), 
field  of  view,  and  image  data  compression. 

3.2.33  Infrared  Sensors 

Standards  for  this  functional  area  are: 

•  None 

Infrared  (IR)  sensors  detect  radiation  (reflected  and  emitted)  at  wavelengths 
longer  than  visible  light.  The  IR  part  of  the  spectrum  is  broader  than  the  visible 
part  and  the  types  of  IR  sensors  can  be  subdivided  into  near  wavelength  infrared 
(near  IR  or  NIR),  short  wavelength  infrared  (SWIR),  middle  wavelength  infrared 
(MWIR),  long  wavelength  infrared  (LWIR),  and  any  number  of  subsets  of  these 
major  categories.  Each  broad  category  of  wavelengths  has  unique  reflection  and 
emittance  characteristics,  analogous  to  visible  colors.  NIR  has  most  of  the 
characteristics  as  Pan,  but  has  better  haze  penetration  and  higher  reflection  by 
water  bearing  cells  in  plants  that  facilitates  healthy  vegetation  characterization 
and  camouflage  detection.  SWIR  has  even  better  haze  penetration  than  NIR  and 
some  reflective  properties  for  camouflage  detection.  MWIR  is  sensitive  to  thermal 
imaging  as  well  as  reflective  infrared  and  works  well  in  low  light-level 
applications.  LWIR  provides  true  thermal  imaging  that  can  be  used  in  total 
darkness. 

As  the  operating  wavelength  of  an  infrared  sensor  increases,  the  technology 
required  to  design  and  construct  the  sensor  becomes  complex  and  more 
expensive.  The  transmittance  of  optical  glass  stops  at  SWIR  and  greater 
wavelengths,  so  the  sensors  need  special  lens  material  or  more  likely  will  use 
reflective  optics  (mirrors).  The  longer  the  wavelength  of  operation,  the  more 
thermal  noise  will  have  to  be  reduced.  This  requires  cooling  of  the  detector  array, 
to  cryogenic  levels  for  LWIR  operation,  and  possibly  the  optics  and  other  parts  of 
the  sensor.  The  composition  of  the  detector  array  is  different  for  IR  than  it  is  for 
Pan,  and  sometimes  multiple  arrays  need  to  be  employed  for  different  IR 
wavelength  categories.  These  characteristics  can  put  demands  on  platform 
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integration  for  cooling  and  on  digital  signal  processing  functions  for  calibration 
and  noise  reduction.  There  are  no  standards  for  IR  sensors. 

3.23.4  Video  Cameras 

Standards  for  this  functional  area  are: 

•  NTSC  and  RS-1 70  for  analog  video 

•  HDTV  and  MPEG-2  for  digital  video 

Motion  video  adds  a  time  dimension  to  imagery,  where  motion  of  objects  and 
other  time-dependent  activities  can  be  directly  observed.  Video  is  really  a  series 
of  still  images  that  overlap  the  same  coverage  and  repeat  the  scene  nominally  30 
times  per  second  which  is  the  commercial  broadcast  standard  frame  rate.  Video 
cameras  usually  employ  zoom  lenses  or  multiple  optics  for  adjusting  viewing  area 
and  detail.  In  addition,  dynamic  flight  control  permits  close  range  imaging  for 
high  resolution,  and  far  range  imaging  for  increasing  area  coverage  with  lower 
resolution. 

Video  cameras  are  most  often  used  on  UAVs  where  they  originally  served  to 
support  the  remote  pilot  during  takeoff  and  landing.  Now  they  have  become 
recognized  as  a  highly  valuable  reconnaissance  asset.  The  cameras  are  very 
similar,  if  not  identical,  to  commercial  models  available  for  commercial  broadcast 
and/or  home  use.  Real-time  video  can  be  broadcast  directly  to  the  warfighters  and 
other  receivers  through  various  communications  systems  using  the  same 
technology  that  the  commercial  television  broadcast  industry  uses. 

For  current  legacy  systems,  the  base  analog  video  standard  is  the  National 
Television  Standards  Committee  (NTSC)  signal  provided  in  RS-170  format.  This 
standard  defines  the  broadcast  industry  standard  image  with  525  lines  of  analog 
luminance  (density)  trace  signals.  It  has  30  unique  frames  per  second.  The  video 
trace  is  interlaced  so  that  there  are  actually  60  fields  or  traces  per  second  of  262 
lines  each.  The  increased  frame  rate  is  used  to  reduce  scene  flicker  on  the  cathode 
ray  tube  or  TV  screen  used  for  display. 

Commercial  industry  is  currently  migrating  away  from  analog  video  components 
to  all-digital  systems.  It  is  anticipated  that  within  five  years,  professional-quality 
analog  video  products  will  no  longer  be  manufactured.  Airborne  reconnaissance 
systems  will  leverage  advances  in  commercial  television  technology  which 
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provides  the  standards  base  for  interoperability  among  commercial  broadcast  and 
military  video  systems.  Additional  benefits  include  improved  video  quality;  inter¬ 
service  and  NATO/allied  forces  interoperability;  improved  protection  from 
obsolescence;  and  lower  life  cycle  costs.  In  fact,  COTS  solutions  are  currently 
available  for  a  complete  end-to-end  digital  video  system  implementation,  • 
adhering  to  the  following  standards: 

•  Uncompressed  digital  video:  CCIR  601  4:2:2  component 

•  Video  time  base:  SMPTE  VITC  Drop  Frame  Recommended  Practices 
(SMPTE  RP 173:  1993  and  SMPTE  RP179:  1994) 

•  Digital  video  compression:  MPEG-2  4:2:2  Profile@Main  Level 
(ISO/IEC  13818-1  Systems,  13818-2  Video,  and  13818-3  Audio) 

•  Digital  video  physical  layer:  SMPTE  259M 

The  key  outstanding  standards  problem  for  video,  from  an  airborne 
reconnaissance  point  of  view,  is  metadata  -  data  about  data.  Developing  a 
standard  for  video  metadata  is  one  of  the  highest  priority  tasks  being  worked  in 
the  CIO’s  Video  Working  Group.  (See  Section  5.1.1  for  more  details.) 

3.2.3.5  Synthetic  Aperture  Radars 

Standards  for  this  functional  area  are: 

•  None 

Radar  systems  transmit  radio  signals  and  measure  the  reflected  energy  from  the 
target.  Power,  frequency,  and  modulation  of  the  transmitted  signal  can  be  altered 
to  achieve  different  effects  of  range,  resolution,  and  penetration.  Radar  sensors 
have  the  ability  to  operate  day  and  night  and  penetrate  clouds,  offering  true  all- 
weather  operation. 

Synthetic  aperture  radar  (SAR)  is  the  most  commonly  used  type  of  radar  for 
imagery  reconnaissance  applications.  The  systems  are  called  synthetic  aperture 
because  the  combination  of  the  individual  radar  returns  effectively  creates  one 
large  antenna  with  an  effective  aperture  size  equivalent  to  the  flight  path-length 
traversed  during  the  signal  integration.  The  formation  of  this  large  synthetic 
aperture  is  what  enables  these  radars  to  produce  images  with  fine  in-track  (for 
azimuthal)  resolution;  the  high  bandwidth  and  pulse  repetition  interval  enables  the 
SAR’s  fine  cross  track  (or  range)  resolution.  The  image  can  be  produced  with 


Page  40 

DRAFT 


DRAFT 


ground  resolutions  less  than  one  foot,  when  operating  in  “spot”  mode,  and 
approach  photographic  appearance  and  interpretability.  In  search  modes,  ground 
sampled  distances  (more  correctly  radar  impulse  response)  is  often  ten  feet  or 
more. 

The  classic  SAR  (above)  is  ill  suited  for  imaging  targets  which  have  rotational 
motion.  They  tend  to  defocus  and  blur  the  image  unless  the  rotational  motion  is 
accurately  predicted  and  compensated  for  in  the  processing  algorithms.  Inverse 
SAR  (ISAR)  systems  use  different  algorithms  that  exploit  the  object’s  rotational 
motion,  rather  than  the  radar’s  relative  velocity,  which  results  in  sharper  images. 

Interferometric  Synthetic  Aperture  Radar  (IFSAR)  systems  produce  three 
dimensional  images  (i.e.,  they  also  produce  elevation  data).  The  IFSAR  system 
operates  by  using  two  separate  antennas  spaced  a  meter  to  several  meters  apart. 
The  systems  employ  two  receivers  and  measure  the  phase  difference  of  the 
received  signal  at  the  second  antenna,  using  the  received  signal  at  the  first  antenna 
as  a  reference.  The  phase  difference  measurement  is  made  by  an  interferometric 
technique.  This  phase  difference  is  then  processed  to  provide  the  third  dimension 
of  information.  IFSAR  systems  are  predominately  experimental  (e.g.,  R&D 
prototypes). 

Currently  there  are  no  standards  for  SAR  sensors  or  for  their  interfaces  with 
associated  pre-processors.  The  need  for  such  interface  standards  will  be  addressed 
in  a  future  version  of  the  ARITA. 

3.2.3.6  Moving  Target  Indicator  Radar 

Standards  for  this  functional  area  are: 

•  None 

Moving  Target  Indicator  (MTI)  Radar  systems  detect  the  movement  of  objects 
within  the  radar’s  field  of  view.  The  range  of  speed  detectable  is  different  for  each 
system  and  is  limited  by  many  design  considerations.  Fields  of  view  are  typically 
very  large  and  can  extend  up  to  200  miles  distance  from  the  radar.  The  processed 
MTI  data  is  normally  displayed  on  a  map  background  and  used  for  area 
surveillance  and  command  and  control  of  force  deployments.  If  the  MTI  radar 
also  has  a  SAR  capability,  then  images  of  specific  targets  can  be  acquired,  or  low 
resolution  search  imagery  can  be  taken  of  limited  areas  for  use  in  place  of  the  map 
background  when  displaying  the  MTI  data. 
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Currently  there  are  no  standards  for  MTI  sensors  or  for  their  interfaces  with 
associated  pre-processors.  The  need  for  such  interface  standards  will  be  addressed 
in  a  future  version  of  the  ARITA. 

3.2.3.7  Spectral  Sensors 

Standards  for  this  functional  area  are: 

•  None 

Spectral  sensors  provide  unique  targeting  and  intelligence  data  based  on 
collection  from  multiple  bands  of  reflected  radiance,  and  from  combinations  of 
bands.  The  primary  reconnaissance  application  for  spectral  data  is  to  detect, 
locate,  and  identify  exigent  targets.  Some  of  the  spectral  sensor  data  will  be  used 
to  form  images;  other  uses  involve  MASENT  exploitation  techniques  as  described 
in  3.2.4.6. 

Spectral  sensors  are  defined  and  categorized  in  the  scientific  community 
according  to  the  number  of  non-redundant  spectral  bands  within  the  sensor.  The 
following  nomenclature  is  generally  accepted: 

•  Multispectral  Imagery  (MSI)  Sensor:  A  sensor  capable  of  receiving 
between  2  and  19  separate  spectral  bands. 

•  Hyperspectral  Imagery  (HSI)  Sensor:  A  sensor  capable  of  receiving 
between  20  and  299  separate  spectral  bands. 

•  Ultraspectral  Imagery  (USI)  Sensor:  A  sensor  capable  of  receiving  300 
or  more  spectral  bands. 

Spectral  sensors  have  individual  detector  arrays  with  various  spectral  responses 
(i.e.,  one  detector  array  for  each  spectral  band).  Each  detector  array  produces  an 
image  (or  image  layer)  corresponding  to  the  spectral  response  in  the  given  band. 
Multiple  image  layers  are  captured  nearly  simultaneously  and  registered  to  each 
other.  Spectral  bandpass  filters  may  be  used  to  change  the  spectral  response  of 
one  or  more  of  the  detector  arrays. 

Spectral  imagery  is  only  beginning  to  be  developed  for  operational  use.  It  is 
possible  to  use  the  different  scene  reflectance  in  each  band  to  detect  and 
distinguish  specific  targets.  Details  that  are  not  observable  with  panchromatic 
(visible)  sensors  may  be  detected  from  the  image  variations  between  multispectral 
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layers.  Spectral  data  may  also  be  used  in  automatic  target  recognition  (ATR) 
and/or  cueing  (ATC)  software  to  provide  more  dependable  performance  than 
panchromatic  imagery. 

Spectral  sensors  typically  produce  very  large  quantities  of  data  due  to  the  fact  that 
there  are  several  layers  (corresponding  to  the  different  bands),  where  each  layer 
contains  the  same  quantity  of  data  as  a  panchromatic  or  IR  image.  This  increase  in 
generated  imagery  data  and  the  technical  challenges  it  presents  are  often  a 
limiting  factor  in  the  design  and  use  of  spectral  sensors.  Recording  and  storing  the 
data,  as  well  as  processing  and  exploiting  it  are  more  difficult  than  for  single 
spectral  imagery.  Transmitting  the  larger  quantity  of  information  over  a  data  link, 
especially  in  real  time,  is  a  formidable  challenge. 

Currently  there  are  no  standards  for  spectral  sensors. 

3.2.3. 8  Image  Quality  Standards 

Standards  for  this  functional  area  are: 

•  National  Imagery  Interpretability  Rating  Scale  (NIIRS) 

There  are  different  National  Imagery  Interpretability  Rating  Scales  (NIIRS)  for 
visible,  IR,  and  SAR  imagery.  There  are  no  corresponding  scales  for  video  or 
spectral  imagery.  However,  a  video  scale  is  being  developed  under  CIO  direction. 

Measuring  image  quality  with  the  NIIRS  requires  the  subjective  judgments  of 
experienced  imagery  analysts.  One  potential  airborne  reconnaissance  operational 
use  of  image  quality  measures  is  monitoring  image  quality  in  a  ground  station. 
Images  could  be  prioritized  so  analysts  could  decide  to  exploit  the  images  with 
lowest  quality  last.  Another  use  could  be  to  detect  problems  in  processing.  One 
candidate  standard  metric  for  this  use  is  based  on  an  objective  metric  -  digital 
power  spectrum  analysis. 

However,  the  Video  Working  Group  (VWG)-sponsored  Video  Image  Quality 
Control  Board  (VIQCB)  is  currently  working  on  a  video  quality  metric  to 
accommodate  the  unique  temporal  aspect  of  video. 


Page  43 

DRAFT 


DRAFT 


3.2.4  MASINT  Front-End  Functions 

The  following  sections  apply  to  the  MASINT  front-end  components  of  the 
airborne  reconnaissance  functional  reference  model  (Figure  3-4).  Two  important 
distinctions  between  MASINT  and  other  intelligence  systems  are  the  maturity  and 
diversity  of  the  component  systems.  The  MASINT  discipline  encompasses  seven 
technological  areas  of  remote  sensing.  Within  each  of  the  seven  areas  there  are 
numerous  implementations,  many  of  which  are  still  in  the  R&D  phase,  which 
makes  the  creation  of  standards  a  much  more  difficult  task.  Where  possible, 
standards  for  MASINT  systems  are  specified  in  this  document;  however,  much 
work  is  ongoing  to  complete  a  set  of  standards.  Instead,  references  to  specific 
systems  are  given  in  this  section  to  indicate  the  broad  scope  and  relative 
immaturity  of  the  MASINT  discipline. 


Figure  3-4:  MASINT  Front-End  FRM 


3.2.4.1  Chemical/Biological  Weapons  Sensors 

Standards  for  this  functional  area  are: 

•  Interface  Specification,  Radio  Frequency  Transmission  Interfaces  for 
DoD  Physical  Security  Systems,  SEIWG-005,  15  December  1981 

Within  the  Chemical  and  Biological  Weapons  (CBW)  area,  there  is  currently  a 
broad  cross  section  of  emerging  technologies  with  few  common  elements.  The 
DARO’s  Technology  Program  Plan  and  Airborne  Reconnaissance  Technical 
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Architecture  Program  Plan  have  shown,  for  example,  that  there  are  at  least  ten 
different  sensor  technologies  that  can  be  applied  to  the  mission  area  of  chemical 
and  biological  weapons  detection.  No  operational  sensor  systems  for  airborne 
MASINT  missions  exist  as  yet.  However,  two  prototype  chemical  sensor  systems 
have  been  field  tested  on  DARO  UAV  systems.  The  tested  systems  include  a 
passive  sensor  system  called  the  Lightweight  Standoff  Chemical  Agent  Detector 
and  a  point  detector  system  called  the  Surface  Acoustic  Wave  Chemical  Agent 
Detector.  No  airborne  biological  systems  have  been  fielded  or  tested. 

CBW  sensors  can  be  logically  categorized  into  four  groups  as  follows: 

Passive,  optical-based  standoff  detectors 

•  Fourier  Transform  Infrared  (FTIR) 

•  Spectral  Sensors  (see  section  3. 2.4.6) 

Active,  optical  based  standoff  detectors 

•  Laser  Imaging  Detection  and  Ranging  (LIDAR) 

•  Differential  Absorption  LIDAR  (DIAL) 

Point  detectors 

•  Surface  Acoustic  Wave  (SAW) 

•  Ion  Mobility  Spectrometer  (IMS) 

•  Fiber-Optic  Wave  Guide  (FOWG) 

•  Optical  Planar  Wave  Guide  (OPWG) 

•  Optical  Antibody-Based  Biosensor 

•  Nerve  Cell 

•  DNA  Analyzer 

Collateral  sensors 

•  Meteorological  (MET) 

The  platforms  used  to  carry  CBW  sensors  include  tactical  UAVs,  manned  aircraft, 
hand  launched  UAVs,  and  cassondes  (canisters  with  sensor  payloads  ejected  from 
aircraft  or  UAVs).  Tactical  UAVs  would  be  the  ideal  candidates  for  passive 
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optical  based  standoff  detectors  but  probably  not  point  detectors  because  of  post 
mission  decontamination  problems.  LIDARS,  with  sufficient  detection  ranges 
must  reside  on  a  manned  platform  because  of  power  considerations.  Since 
chemical  agent  clouds  are  rapidly  dissipated  by  wind  and  rain,  toxic  agents  must 
be  deployed  in  close  proximity  to  the  targeted  forces  and  consequently,  point 
detectors  must  also  be  close  in.  Point  sensors  would  be  hosted  by  cassondes,  small 
UAVs,  or  other  attritable  platforms  that  sample  toxic  clouds  and  relay  information 
back  to  analysis  nodes.  This  alleviates  the  decontamination  problem  for  more 
expensive  reconnaissance  assets,  and  in  many  cases  could  obviate  the  need  for 
manned  platforms,  with  all  their  inherent  risks. 

Accurate  knowledge  of  weather  conditions  is  crucial  to  predict  the  boundaries  of 
CBW  agents.  Miniature  meteorological  sensors  that  measure  and  transmit  data 
will  be  ejected  from  platforms  (dropsondes)  to  detail  atmospheric  conditions 
(wind,  temperature,  humidity,  position,  and  barometric  pressure)  while 
descending  through  the  air.  Sensor  types  can  be  configured  to  send  meteorological 
data  after  ground  impact  as  well.  The  CBW  architecture  must  accommodate  these 
sensors  and  input  this  data  to  meteorological  models  along  with  all  other  CBW 
sensor  data. 

The  standard  used  for  unattended  ground  sensors  (SEIWG-005),  cited  in  Section 
3.2A.3,  is  also  applicable  to  CBW  sensors. 

3.2.4.2  Laser  Warning  Receivers 

Standards  for  this  functional  area  are: 

•  None 

Laser  intelligence  (LASINT)  encompasses  collection  sensors  for  signature 
development  and  laser  threat  characterization.  This  function  provides  near-real¬ 
time  battlefield  laser  warning  and  counter-measures.  Essentially,  laser  warning 
receivers  (LWR)  provide  an  inexpensive,  quick  capability  to  detect,  identify,  and 
characterize  foreign  laser  weapons  and  designators. 

The  following  sensors  are  considered  part  of  a  comprehensive  set  of  airborne 
LWR/LASINT  systems: 

•  Cluster  Halt 

•  LOFT 
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•  LASINT  LWR  Sensor  (USN  R&D  effort) 

Laser  warning  receivers  must  have  interfaces  to  on-board  alarm  systems  and 
connect  to  warning  dissemination  systems  for  alerting  other  aircraft  and/or  ground 
systems.  This  dissemination  could  be  implemented  through  the  direct  reporting 
functions  described  in  Section  3.7.1,  but  there  are  no  alarm  interface  standards 
available.  Raw  LASINT  data  for  signature  analysis  and  Order  of  Battle  (OB) 
requires  a  different  communications  or  recording  path  than  the  alarms.  As  with 
most  MASINT  functionality,  a  dual  path  is  required  with  LASINT/LWR,  one  that 
gives  immediate  reconnaissance  information/identification  and  another  that 
transfers  huge  data  files  to  ground  exploitation  centers. 

3.2.4.3  Unattended  Ground  Sensors 

Standards  for  this  functional  area  are: 

•  Interface  Specification,  Radio  Frequency  Transmission  Interfaces  for 
DoD  Physical  Security  Systems,  SEIWG-005,  15  December  1981 

Unattended  ground  sensors  (UGS)  are  MASINT  sensors  that  can  be  emplaced  by 
airborne  platforms,  hand  emplaced  by  special  forces,  and  use  platforms  as  relay 
communications  back  to  a  common  exploitation  station.  Typically,  UGS  systems 
are  fairly  small,  have  autonomous  power  and  communications,  and  transmit  alarm 
messages  when  seismic,  acoustic,  magnetic,  infrared  (day-night  imaging),  and 
other  sensors  are  activated. 

Advanced  UGS  systems  contain  embedded  automatic  target  recognition 
algorithms  to  recognize  specific  targets  such  as  SCUD  launchers  and  mobile 
command  centers.  This  is  accomplished  by  extracting  key  attributes  from  target 
signatures  such  as  engine  type,  transmission  type,  exhaust  location,  number  of 
axles,  weight  and  weight  distribution. 

Available  sensors  include: 

•  Tactical  Reconnaissance  Sensor  System 

•  Improved  Remotely  Monitored  Battlefield  Sensor  System 

•  Miniature  Intrusion  Detection  System 

•  Selected  commercial  sensors 
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Sensors  in 


development  include: 

Steel  Rattler  (formerly  called  Unattended  MASINT  System) 
Internetted  Unattended  Ground  Sensor  (IUGS) 

REMOTE  SENTRY  (P/O  Rapid  Force  Projection  Initiative) 
Air  Mobile  Ground  Security  and  Surveillance  System 
DNA  Unattended  Sensor  Program 
Wide  Area  Munitions  (WAM) 


The  following  is  an  “all-encompassing”  military  standard  that  governs  the  design 
of  unattended  ground  sensors  (e.g.,  it  covers  RF,  data  formats,  transmission 
protocols,  connectors,  etc.):  Interface  Specification,  Radio  Frequency 
Transmission  Interfaces  for  DoD  Physical  Security  Systems,  SEIWG-005,  15 
December  1981 

3.2.4.4  Air  Sampling 

Standards  for  this  functional  area  are: 

•  None 

Of  all  the  MASINT  functions,  air  sampling  is  the  oldest  and  most  unique 
technique.  Air  sampling  captures  physical  samples  of  atmospheric  gases  and 
particles.  Additionally,  beta  and  gamma  radiation  detectors  are  used  on  WC-135s 
to  guide  the  flight  path  through  the  plumes.  This  MASINT  function  is  not  real 
time:  no  on-board  processing  is  required,  only  power,  space,  and  inlet  ports  within 
the  airframe.  The  high  degree  of  precision  needed  to  analyze  the  samples  can  only 
be  achieved  in  the  laboratory. 

3.2.4.5  Synthetic  Aperture  Radars 

Standards  for  this  functional  area  are: 

•  None 

Functionally,  SAR  sensors  are  common  to  both  IMINT  and  MASINT  disciplines. 
MASINT  does  not  require  additional  SAR  instruments  but  uses  the  raw  data  from 
the  IMINT  collection  systems  (Section  3. 2. 3. 5)  for  specialized  MASINT 
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processing  and  exploitation.  Although  MASINT  processors  will  normally  process 
the  data  post  mission,  future  systems  will  include  on-board  SAR  phase  history 
(PH)  processing  with  products,  along  with  raw  in-phase  and  quadrature-phase 
(I&Q)  data,  available  to  ground  systems.  Therefore,  standards  affecting 
interoperability  with  MASINT  SAR  phase  history  processing  systems  must  be 
considered. 

Currently  there  are  no  standards  for  SAR  sensors  or  for  their  interfaces  with 
associated  pre-processors.  The  need  for  such  interface  standards  will  be  addressed 
in  a  future  version  of  the  ARITA. 

3.2.4.6  Spectral  Sensors 

Standards  for  this  functional  area  are: 

•  None 

MASINT  functions  exploit  spectral  data  acquired  with  the  same  spectral  sensors 
as  those  used  for  imagery  applications  (see  Section  3.23.7).  One  key  difference  is 
that  rather  than  using  imagery  analysis  techniques,  MASINT  applications  process 
the  spectral  data  directly  (i.e.,  spectral  signature  analysis)  to  detect,  classify, 
characterize,  and  identify  various  chemicals,  biological  compounds,  and  other 
affluents. 

3.2.4.7  RF  Sensors 

The  technologies  discussed  in  the  following  subsections  make  up  the  RF  portion 
of  the  MASINT  technical  architecture. 

3.2.4.7.1  Passive  Bistatic  Radar 

Standards  for  this  functional  area  are: 

•  None 

Passive  bistatic  radar  technology  is  based  on  non-cooperative  coherent 
exploitation  of  random  background  ambient  signals.  Signal  exploitation  is  for 
purposes  of  airborne  and  ground  based  target  detection,  tracking,  and 
identification.  The  non-cooperative  exploited  signal  can  be  narrowband  or 
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wideband  at,  any  carrier  frequency  from  HF  through  X-band.  The  technology 
employs  several  processing  modes  that  utilize  cooperative  and  non  cooperative 
emitters  from  commercial  broadcast  services  through  surveillance  radars. 

3.2.4.7.2  Foliage  Penetration 

Standards  for  this  functional  area  are: 

•  None 

Exploitation  of  foliage  penetration  (FOPEN)  signatures  will  detect  and  potentially 
classify  targets  that  are  underground  or  concealed  by  dense  foliage.  Systems 
ideally  would  be  used  to  gather  information  on  communications,  oil,  gas,  and 
power  lines;  toxic  waste  dump  sites;  underground  tunnels;  command  bunkers; 
antipersonnel  mines;  and  all  concealed  man-made  objects  using  RF  and  acoustic 
technology.  RF  based  systems  generally  employ  broadband  (nominally  200-400 
MHz)  low  power  emitters  (1  watt).  FOPEN  processing  algorithms  require 
multiple  polarization  antennas  (normally  one  vertical  antenna,  one  horizontal 
polarized  receive  antenna,  one  transmit  antenna)  to  optimize  signatures  from  man 
made  objects  and  eliminate  return  clutter  from  large  natural  objects  such  as  large 
tree  trunks.  Acoustic  FOPEN  combines  acoustic  signatures  analysis,  for  example, 
artillery  fire  sound,  with  phased  microphone  direction  finding  arrays  to  locate  and 
identify  hidden  targets.  Microphone  arrays  would  be  integrated  on  a  UAV  or 
other  platform  as  part  of  an  exigent  target  detection  suite,  feeding  sensor 
information  into  advanced  MASINT  automatic  target  recognition  functions  with 
direct  sensor-to-shooter  product  dissemination. 

3.2.4.7.3  Ultra-Wideband 

Standards  for  this  functional  area  are: 

•  None 

Ultra-wideband  sensors  exploit  non-intentional  RF,  detect  wideband 
communications  and  tracking  systems,  or  provide  all-weather  missile  launch 
(plume)  detection  by  characterizing  rocket  motor  propellants  and  consequently 
the  launch  vehicle.  An  ultra-wideband  receiver  requires  nominal  operation  over  a 
band  extending  from  100  MHz  to  10  GHz  with  greater  than  2  GHz  instantaneous 
bandwidth  (10  GHz  for  strong  signals  with  post  processing).  This  is  achieved 
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through  the  use  of  antennas  and  receivers  specifically  developed  for  ultra- 
wideband  (wideband  blade  antenna)  use  with  fiber  optic  feeds  and  fiber  optic 
distribution  of  intercepted  RF  signals. 

3.2.4.7.4  Non-Cooperative  Target  Identification 

Standards  for  this  functional  area  are: 

•  None 

This  is  a  broad  category  of  MASINT  RF  techniques  including  analysis  of  radar 
cross  section  (RCS)  signatures,  feature  modulation  spectrum,  and  in  general,  it 
characterizes  targets  using  the  totality  of  all  unintentional  RF  emissions.  Ultra- 
wideband  RF  sensors  collect  against  a  wide  variety  of  RF  emissions  from  military 
equipment  including  directed  energy  weapons. 

3.3  Navigation,  Timing,  and  Ancillary  Data 

Standards  for  this  functional  area  are: 

•  Timing  data  synchronized  to  the  United  States  Naval  Observatory 
Coordinated  Universal  Time  (USNO-UTC) 

•  A  one-pulse  per  second  (PPS)  time  tick  provided  over  a  MIL-STD- 
J553B  bus 

•  IRIG-B  timing  standard 

•  SMPTE  VITC  Drop  Frame  Recommended  Practices  (SMPTE  RP1 73: 
1993  and  SMPTE  RP 179:  1994)  (video  time  base) 

The  navigation,  timing,  and  ancillary  data  functions,  color  coded  blue  in  the 
airborne  reconnaissance  FRM  (Figure  3-1),  are  very  important  common  support 
functions  that  directly  affect  the  overall  quality  of  the  finished  airborne 
reconnaissance  product.  All  processing  and  exploitation  functions  use  navigation, 
timing,  and  ancillary  data  in  some  way  when  processing  the  sensor  data.  In 
general,  navigation  data  is  information  about  the  position  and  attitude  (roll,  pitch, 
and  yaw)  of  the  collection  platform,  timing  data  is  an  exact  reference  to  absolute 
real-time,  and  ancillary  data  is  information  about  the  sensors  and  payload  (e.g., 
sensor  mode,  settings,  commands  invoked,  etc.). 
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Functionally,  navigation,  timing,  and  ancillary  data  are  “captured”  in  the  front- 
end  subsystems  and  disseminated  to  all  other  functions.  Navigation  data  is 
captured  from  the  platform’s  inertial  navigation  subsystem  and/or  GPS;  timing 
data  is  captured  from  the  GPS  and  an  on-board  atomic  clock  frequency  reference; 
and  ancillary  data  is  captured  from  the  sensors  themselves  and  the  sensor  control 
functions.  The  key  term  “data  capture”  includes  data  recorded  either  periodically 
(e.g.,  record  the  sensor  mode  every  15  seconds)  or  upon  detection  of  specified 
triggering  events  (e.g.,  record  the  sensor  mode  whenever  it  is  changed). 
“Recording”  refers  to  real-time  functions  (on-board  the  platform)  which  logically 
attach  time-tag  data,  navigation  data,  and  ancillary  data  to  the  collected  sensor 
data.  The  critical  aspect  is  maintaining  strict  correlation  of  sensor  data  with  the 
associated  navigation,  timing,  and  ancillary  data. 

Timing  data  synchronized  to  the  United  States  Naval  Observatory  Coordinated 
Universal  Time  (USNO-UTC)  is  mandated.  It  will  include  a  common  precision 
frequency  reference  based  on  a  rubidium  or  cesium  atomic  clock  reference 
standard.  Accuracy,  precision,  and  latency  will  be  set  to  meet  the  worst-case  real¬ 
time  processing  requirements  for  SIGINT,  IMINT,  and  MASINT  payloads. 

From  the  airborne  platform  inertial  navigation  system  (INS)  and  Global 
Positioning  System  (GPS),  navigational  data  and  a  one-pulse  per  second  (PPS) 
time  tick  are  provided  over  a  MIL-STD-1553B  bus.  A  fiber  optic  version  of 
1553B  (i.e.,  MIL-STD-1773)  is  under  investigation. 

For  video,  the  SMPTE  VITC  Drop  Frame  time  base  will  be  used  for 
synchronization  and  timing.  For  all  other  data  sources,  the  IRIG-B  standard  will 
be  used  in  the  case  where  a  general  purpose  time  reference  is  provided  with  a 
sensor  data  stream  (e.g.,  on  the  audio  track  of  a  mission  tape  recorder  or  a  time 
reference  channel  on  the  data  link).  IRIG-B  calls  for  a  1  KHz  signal  with  timing 
information  encoded  using  pulse-width  modulation.  The  IRIG-B  message  uses 
binary  coded  decimal  (BCD)  to  encode  the  Julian  date  (three  digits)  and  time  of 
day  (six  digits)  as  follows:  DDDHHMMSS.  In  some  cases  a  high-precision  time- 
tag  will  also  be  recorded  with  the  data.  Navigation  data  includes  the  following 
data  elements  (examples): 

•  Altitude  (AGL  and  MSL) 

•  Latitude  and  longitude  (or  UTM) 

•  GPS  delta 
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•  Heading 

•  Ground  speed  and  acceleration 

•  Drift  angle 

•  Cross  track 

•  Roll,  pitch,  and  yaw 

Ancillary  data  is  particularly  important  for  IMINT  missions  and  payloads. 
Example  data  elements  include: 

•  Sensor  identification  (model,  type,  serial  number) 

•  Sensor  configuration  (installed  options,  lens  type  &  identification) 

•  Film  type  (if  applicable) 

•  Calibration  data  (such  as  identification  of  dead  CCD  elements  and  lens 
aberrations) 

•  Camera  location 

•  Forward  and  side  look  angles 

•  Camera  mode 

•  Frame  number 

•  Focal  length,  field  of  view,  and  exposure 

Currently,  the  specific  data  elements,  format,  and  details  for  transmission  of  the 
data  are  usually  specified  in  Interface  Control  Documents  (or  equivalent  system- 
specific  specifications)  that  are  unique  for  given  system-to-system  interfaces.  An 
“across-the-board”  standard  would  greatly  enhance  interoperability  among 
airborne  reconnaissance  systems;  for  example,  it  would  provide  a  basis  for 
allowing  alternative  ground/surface  systems  to  receive  and  process  information 
from  platforms  other  than  the  one(s)  they  were  specifically  designed  for.  A 
common  metadata  standard  for  airborne  imagery  is  being  developed  by  CIO  and 
DARO  and  will  be  incorporated  in  a  future  version  of  the  ARITA.  The 
requirement  for  precise  geopositioning  (e.g.,  for  TDOA/FDOA  calculations  and 
IFSAR/SAR  PHD  processing)  demands  highly  accurate  and  precise  timing  and 
navigation  data.  Detailed  standards  are  under  development  and  will  be  adopted 
across  the  INTs  in  a  future  version  of  the  ARITA. 


Page  53 

DRAFT 


DRAFT 


3.4  Networking  Functions 

The  networking  functions  (color  coded  red  in  the  FRM,  Figure  3-1)  provide  four 
key  attributes  as  described  in  the  following  subsections. 

3.4.1  Command  and  Control  Network 

Standards  for  this  functional  area  are: 

•  Ethernet  (10  Mb/s) 

•  Fast  Ethernet  (100  Mb/s) 

•  FDDI  (100  Mb/s  dual  counter  rotating  ring) 

•  ATM/SONET  (155  Mb/s)  (JTA  Section  3. 2.2. 2.5  and  3.2.3.3) 

•  Fibre  Channel  (800  Mb/s) 

The  primary  function  of  the  command  and  control  (C2)  network  is  to  transport  and 
distribute  near-real-time  commands  to  control  on-board  sensors  and  other 
functional  components  in  the  FRM.  C2  network  functions  are  very  similar  to  the 
multimedia  network,  the  key  difference  being  data  throughput.  In  fact,  the  C2 
network  functions  can  be  implemented  on  the  same  physical  LAN  as  the 
multimedia  network.  For  many  applications,  the  FDDI  network  referenced  below 
is  more  than  adequate  to  accommodate  the  C2  information  flow. 

3.4.2  High-Speed  Data  Flow  Network 

Standards  for  this  functional  area  are: 

•  Fibre  Channel 

The  high-speed  data  flow  network  provides  the  transport  and  distribution 
functions  for  real-time  exchange  of  raw/pre-processed  digital  sensor  data  between 
processing  components.  In  order  to  preserve  real-time  synchronization  of  vital 
sensor  data,  the  high-speed  (500  to  1000  megabits  per  second)  data  flow  network 
must  have  a  low,  deterministic  end-to-end  latency. 

The  SIGINT  community  has  selected  ANSI  X3.230,  Fibre  Channel  Physical  and 
Signaling  Interface  (FC-PH),  as  the  lowest  risk  technology  for  the  high-speed  data 
flow  network.  It  offers  the  following  technical  characteristics  which  should  be 
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adequate  to  meet  the  functional  needs  of  IMINT  and  MASINT  sensors  as  well  the 
SIGINT  applications  for  which  it  was  selected  as  a  technology  standard. 

•  Layered  high  speed  serial  transport  standard 

•  Scaleable  to  support  data  rates  of  12.5,  25,  50,  and  100  megabytes  per 
second  (100  Mbytes  per  second  equates  to  1.0625  Giga-baud  fiber 
rates) 

•  Support  point-to-point  links  and  non-blocking  switching  matrix 

•  Designed  to  replace  physical  interfaces  for  IPI-3  (Intelligent  Peripheral 
Interface),  SCSI  II  and  Ultra  SCSI  (Small  Computer  System 
Interface),  and  HIPPI  (High  Performance  Parallel  Interface) 

•  Being  applied  to  high  speed  LANs 

-  TCP/IP  (Transport  Control  Protocol  /  Internet  Protocol) 

-  Real-time  and  arbitrated  rings/loops 

-  UDP  (User  Datagram  Protocol)  over  IP 

3.4.3  Multimedia  Network 

Standards  for  this  functional  area  are: 

•  Ethernet  (10  Mb/s) 

•  Fast  Ethernet  (100  Mb/s) 

•  FDDI  (1 00  Mb/s  dual  counter  rotating  ring) 

•  ATM/SONET  (155  Mb/s)  (JTA  Section  32.2.2.5  and  32.3.3) 

•  Fibre  Channel  (800  Mb/s) 

The  multimedia  network  provides  the  transport  and  distribution  functions  for 
near-real-time  distribution  of  processed  sensor  data  and  metadata  tagged  to  the 
sensor  data  (e.g.,  information  about  the  sensors  and  platform).  It  is  similar  to  the 
high-speed  data  flow  network,  but  the  multimedia  network  can  introduce  small 
non-deterministic  delays  (latency)  since  it  does  not  have  to  support  true  real-time 
communications  requirements.  However,  it  must  be  designed  (data  rate,  number 
of  nodes,  media  access  protocol)  such  that  the  maximum  latency  through  the 
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network  meets  the  near-real-time  requirements  for  networking  multimedia  data  - 
spectral  data,  digital  audio,  video,  graphics,  imagery,  and  MASINT  sensor  data. 

The  ARITA  recommends  FDDI  or  Fast  Ethernet  for  the  multimedia  network. 
Although  ATM  data  rates  may  be  preferable  over  FDDI  and  Fast  Ethernet, 
especially  for  IMINT  and  multispectral  applications,  the  lack  of  maturity  of  ATM 
LAN  technology  precludes  its  selection  at  this  time. 

The  following  are  key  FDDI  technical  characteristics. 

•  Token  ring  fiber  optic  network  (62.5/125  micron  multi-mode  fiber) 

•  Dual  counter-rotating  fiber  optic  rings  for  redundancy 

•  100  megabit  per  second  data  rate  (125  mega-baud  fiber  rate) 

•  Maximum  of  500  connections  (stations) 

•  Maximum  of  2  kilometers  distance  between  stations 

•  Maximum  frame  size  of  4500  octets 

•  Bit  error  rate  of  less  than  2.5  X  10'12 

•  1300  nanometer  LED  transmitter 

•  Laser  transmitter  can  be  used  on  single  mode  fiber 

Fast  Ethernet  is  similar  to  FDDI  in  performance.  Two  key  differences  are  that 
Ethernet  doesn’t  use  dual  counter-rotating  ring  topology,  and  uses  carrier-sense 
multiple  access  with  collision  detection  access  protocol  (CSMA/CD)  rather  than 
the  token  ring  protocol  used  in  FDDI. 

3.4.4  Data  Link 

Standards  for  this  functional  area  are: 

•  System  Description  Document  for  CDL,  Specification  #7681996,  5 
May  1993 

•  System  Specification  for  the  CDL  Segment,  Class  1,  Specification 
#7681990,  draft-C,  11  April  1996 

The  data  link  provides  for  near-real-time  communications  between  the  airborne 
platform  and  ground/surface  functions.  Note  that  the  FRM  (Figure  3-1)  is 
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notional,  and  different  airborne  reconnaissance  system  implementations  may 
place  specific  functions  on  different  sides  of  the  data  link  interface.  For  example, 
the  SAR  image  formation  function  is  allocated  to  the  digital  signal  processing 
(DSP)  block  in  the  FRM,  but  actual  equipment  performing  this  function  could  be 
implemented  in  ground/surface  system  in  some  instances.  Similarly,  operator 
oriented  database  functions,  reach  back,  and  other  functions  shown  to  be 
ground/surface  based  in  the  FRM  can  actually  be  implemented  on-board  manned 
aircraft. 

An  OASD  (C3I)  Policy  Letter,  dated  18  October  1994,  requires  the  Common  Data 
Link  (CDL)  be  used  for  all  primary  data  links  in  airborne  reconnaissance  systems. 
CDL  is  a  full  duplex,  jam  resistant,  point-to-point,  microwave  communications 
system  developed  by  the  Government  for  use  in  imagery  and  signals  intelligence 
systems.  It  provides  an  interoperable,  high  bandwidth,  digital  data  link  for  air-to- 
ground,  air-to-surface,  and  air-to-satellite  (relay)  communications  in  airborne 
reconnaissance  systems.  The  term  “CDL”  actually  refers  to  a  family  of 
interoperable  data  links  offering  alternative  levels  of  capabilities  for  different 
specific  applications.  In  other  words,  the  “generic”  CDL  can  be  scaled  and 
configured  in  various  ways  to  provide  data  link  capabilities  required  for  specific 
airborne  reconnaissance  mission  requirements.  For  example,  configuration 
options  include  choices  of  operating  RF  band  (X  or  Ku),  data  rate  (up  to  274 
megabits  per  second  on  the  return  link),  and  transmission  power  (offering  design 
trades  for  size,  weight,  power,  and  range).  Interoperability  among  the  CDL  family 
of  datalinks  is  achieved  by  specifying  the  data  link  waveform  (RF  and  digital), 
controlling  and  coordinating  hardware  configuration  options,  and  managing  pre¬ 
planned  product  improvement  and  technology  insertion  efforts  to  maintain 
backwards  compatibility  with  fielded  systems.  For  detailed  technical  information 
on  CDL  refer  to  the  System  Description  Document  for  CDL,  Specification 
#7681996,  5  May  1993,  and  the  System  Specification  for  the  CDL  Segment, 

Class  1,  Specification  #7681990,  draft-C,  11  April  1996. 

CDL  provides  “standardized”  command  link  and  return  link  services.  The 
command  link  operates  at  a  200  kilobits  per  second  (spread  spectrum)  data  rate 
and  provides  services  for  transmitting  data  to  the  airborne  platform  (e.g., 
commands  to  the  platform  and/or  sensor  equipment,  secure  voice,  ranging  and 
navigation  corrections,  and  commander’s  tactical  terminal  (CTT)  link  data).  The 
return  link  operates  at  a  either  10.7,  137,  or  274  megabits  per  second  data  rates 
and  provides  services  for  transmitting  data  from  the  airborne  platform  (e.g., 
sensor  data,  platform  navigation  data,  secure  voice,  etc.). 
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CDL  communications  links  through  satellite  utilize  different  data  rates  than  the 
other  line-of-sight  CDLs.  The  return  link  operates  at  2xT-l(3.088  megabits  per 
second),  T-l  (1.544  megabits  per  second),  T/2  (772  kilobits  per  second),  and  T/4 
(386  kilobits  per  second)  data  rates  and  provides  services  for  transmitting  data 
from  the  remoted  airborne  platform  (e.g.,  sensor  data,  platform  navigation  data, 
secure  voice,  etc.).  The  command  link  operates  from  200  bits  per  second  up  to  6 
kilobits  per  second  over  X  band  DSCS  satellites  and  up  to  64  kilobits  per  second 
data  rate  over  commercial  Ku  band  satellites  and  provides  services  for 
transmitting  data  to  the  remoted  airborne  platform  (e.g.,  command  and  control  of 
sensors,  platform  (UAVs),  secure  voice,  CTT  data  link). 

The  standardized  channel  assignments  for  data  multiplexing  on  the  command  link 
and  return  link  are  shown  in  Figure  3-5  and  Figure  3-6  respectively.  These 
assignments  reflect  current  design  practice,  but  a  more  flexible  scheme  is  needed 
to  accommodate  future  requirements  (such  as  variable  data  rates  from  sensor 
outputs).  In  this  regard,  the  CDL  will  migrate  to  a  LAN  interface  standard  (such 
as  ATM  or  Fast  Ethernet)  which  will  provide  a  more  robust,  flexible,  and 
transparent  interface  between  airborne  and  ground/surface  networks. 

Legacy  video  systems  currently  use  analog  components;  however,  digital  video  is 
preferred  and  is  the  desired  goal.  To  provide  a  clear  migration  path  toward  an  all- 
digital  system,  any  upgrades  to  existing  systems  should,  at  a  minimum,  support 
dual-capable  analog/259M  equipment.  CDL  will  be  used  for  the  primary  data  link 
and  real-time  dissemination  to  warfighters  can  be  supported  by  either  the 
industry-standard  DSS-based  JBS/GBS  or  NTSC  analog  broadcast  methods. 
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Figure  3-5:  CDL  Channelization  Standard  -  Command  Link 
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Figure  3-6:  CDL  Channelization  Standard  -  Return  Link 
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3.5  High  Performance  Processing  Functions 

High  performance  processing  functions  (color  coded  orange  in  the  FRM,  Figure 
3-1 :  Airborne  Reconnaissance  FRM)  generally  refer  to  real-time  processing 
operations  performed  on  raw  (or  pre-processed)  sensor  data  and  real-time  system 
control  functions  typically  performed  in  airborne  reconnaissance  subsystems. 

The  term  “real-time  processing”  refers  to  the  ability  to  process  data  at  computing 
speeds  fast  enough  to  keep  up  with  continuous,  sustained  sensor  data-rates  with 
no  data  buffering.  The  term  also  refers  to  the  ability  to  time-tag  sensor  data  with 
great  accuracy  and  precision,  which  may  be  measured  in  nanoseconds  (e.g., 
accuracy  of  marking  an  event  to  an  absolute  time  reference  might  be  ±  50 
nanoseconds,  and  precision  might  be  to  the  nearest  nanosecond).  Similarly,  the 
term  “real-time  system  control”  refers  to  the  ability  to  invoke  sensor  (and  other 
subsystem)  commands  at  an  exact  instant  in  time,  typically  with  accuracy 
measured  in  microseconds. 

Functional  descriptions  for  the  digital  signal  processing,  system  processing  and 
control,  and  encrypted  storage  functional  areas  are  given  in  the  following 
subsections. 

3.5.1  Digital  Signal  Processing  Functions 

Standards  for  this  functional  area  are: 

•  Digital  video:  MPEG-2  4:2:2  Profde@Main  Level  (ISO/IEC  13818-1 
Systems,  13818-2  Video,  and  13818-3  Audio) 

•  Digital  imagery:  Joint  Photographic  Experts  Group  (JPEG)  image 
compression 

•  Common  Image  Processor  (emerging) 

The  digital  signal  processing  (DSP)  functions  are  generally  “number  crunching” 
mathematical  operations  performed  on  the  sensor  data  in  real-time.  Sensor  data  is 
input  from  the  SIGINT,  IMINT,  and/or  MASINT  front-ends  via  the  high-speed 
data  flow  network.  Processed  data  is  output  to  subsequent  functions  (e.g., 
processing,  storage,  or  direct  reporting)  via  the  multimedia  network.  Currently,  no 
standards  exist  for  all  DSP  functions  although  some  are  under  development. 

Example  DSP  functions  in  the  SIGINT  domain  include  the  following: 
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•  Digital  filtering  (sub-band  tuning,  channelization,  notch  filtering) 

•  Transformations  (fast  fourier  transforms  (FFTs),  spectrum  analysis) 

•  Signal  analysis  and  demodulation  (modulation  type,  parameterization, 
decoding) 

•  Time  difference  of  arrival  (TDOA),  differential  doppler,  and  precise 
geopositioning 

•  Direction  finding 

•  Pulse  processing 

•  Search 

Example  DSP  functions  in  the  IMINT  domain  include  the  following: 

•  Image  formation  (S  AR  phase  history  processing) 

•  Transformations  (FFTs,  discrete  cosine  transforms  (DCTs)) 

•  Image  compression  algorithms 

•  Automatic  target  detection  and  automatic  target  recognition  algorithms 

•  Digital  filtering  (haze  removal,  edge  enhancement) 

•  Radiometric  corrections 

Example  DSP  functions  in  the  MASINT  domain  include  the  following: 

•  Similar  functions  as  for  SIGINT  and  IMINT 

•  SAR  phase  history  processing 

•  Spectral  analysis 

•  Signature  characterization  and  analysis 

The  Common  Imagery  Processor  (CIP)  program  is  directed  at  standardizing  some 
of  the  DSP  functions  for  imagery.  Originating  from  the  CIGSS  initiative,  the 
DARO  funded  the  initial  CIP  program  to  develop  a  proof-of-concept  capability 
for  imagery  ground/surface  systems  to  demonstrate  the  feasibility  of  processing 
data  from  multiple  IMINT  sensor  subsystems  in  a  single,  common  processor.  The 
functions  would  be  similar  to  those  cited  above  for  the  IMINT  DSP  functions. 

The  CIP  will  interface  with  sensors  of  various  types  (SAR,  electro-optical,  and 
IR),  and  from  various  manufacturers.  If  the  proof-of-concept  is  successful,  the 
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DARO  will  assess  whether  a  CIP  follow-on  program  will  be  pursued  as  a  standard 
technology  for  IMINT  ground/surface  systems. 

The  services  also  have  been  migrating  to  common  SIGINT  processors  to  conserve 
R&D  dollars  and  lower  recurring  costs  through  multi-service  purchases.  In 
addition,  the  SIGINT  community’s  JASA  initiatives  include  standardizing  some 
of  the  real-time  SIGINT  processors  (e.g.,  SEI  processors,  PROFORMA,  ELINT, 
multichannel,  etc.).  Recent  R&D  shows  promise  for  a  shoe-box  size  CRAY  super¬ 
computer  that  will  enhance  the  capability  to  process  multiple  types  of  signals 
simultaneously  through  state-of-the-art  technology  (e.g.,  Marquise,  S90E). 
Massively  parallel  super-computers  enable  multiple  signal  processing  algorithms 
to  execute  concurrently  which  widens  the  instantaneous  spectral  coverage.  This 
type  of  technology  will  become  more  prevalent  in  airborne  reconnaissance 
systems,  especially  where  mission  requirements  call  for  high  performance 
processing  in  airborne  components  of  the  system. 

For  digital  video,  MPEG-2  4:2:2  Profile@Main  Level  (ISO/IEC  13818-1 
Systems,  13818-2  Video,  and  13818-3  Audio)  is  the  designated  standard. 

The  only  other  applicable  technology  standards  identified  to  date  are  for  image 
compression  algorithms.  Airborne  reconnaissance  systems  should  use  image 
compression  algorithms  specified  in  the  National  Imagery  Transmission  Format 
Standards  (NITFS).  Per  that  standard,  which  currently  applies  only  to  still  images, 
Joint  Photographic  Experts  Group  (JPEG)  is  preferred. 

3.5.2  System  Processing  and  Control  Functions 

Standards  for  this  functional  area  are: 

•  None 

This  area  refers  to  those  functions  that  are  typically  implemented  in  the  platform’s 
subsystems  to  effect  overall  control  of  the  reconnaissance  payload  (e.g.,  sensors 
and  processing  subsystems).  The  principal  function  is  making  real-time 
commands  to  the  front-end  and  DSP  functions*  to  manage  and  control  the  remote 


* 

Commanding  the  DSP  functions  is  applicable  only  if  they  are  performed  in  the  platform’s  subsystems  (e.g., 
on-board  SAR  processing  and/or  SIGINT  signal  processing).  If  DSP  functions  are  performed  in 
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sensing  process  (collection)  and  real-time  processing  of  the  sensors’  data.  This 
may  involve  executing  a  preplanned  target  acquisition  plan  (e.g.,  in  the  case  of 
autonomous  UAV  operations),  or  it  may  involve  responding  to  operator  command 
and  control  received  from  operator  workstations  either  on-board  or  remoted 
through  the  data  link.  In  the  case  of  operator-invoked  commands,  latency  is  a  key 
design  concern  (i.e.,  delay  from  operator  action  to  execution  of  the  command,  and 
return  of  the  expected  response  back  to  the  operator). 

Functionally,  as  shown  in  the  FRM  (Figure  3-1),  the  system  processing  and 
control  functions  use  the  high  speed  data  flow  network  for  the  real-time  interfaces 
with  the  front-end  and  DSP  functions.  The  C2  and  multimedia  networks  are  used 
for  interfaces  with  other  functions. 

Other  system  processing  and  control  functions  include  the  following: 

•  System  initialization  and  downloading/uploading  application  programs 

•  System  diagnostics,  fault  detection/isolation,  recovery,  and  calibration 

•  Automated  reporting  (readouts)  and  dissemination 

•  Encryption  and  decryption  of  data 

•  Sensor  cross-cueing  (either  same  platform  or  multiple  platforms) 

•  Data  correlation  fusion 

Currently  there  are  no  technology  standards  identified  for  system  processing  and 
control  functions. 

3.5.3  Encrypted  Storage  Functions 

Standards  for  this  functional  area  are: 

•  None 

Encrypted  storage  provides  the  capability  to  store  classified  algorithms,  data,  etc. 
necessary  to  support  the  mission  while  allowing  the  platform  to  be  operated  at  an 


ground/surface  subsystems  (e.g.,  IMINT  common  imagery  processor  functions),  real-time  commanding  is 
limited  to  the  special  pre-processing  functions  and  remote  sensor  controls  in  the  front-end  functional  area. 
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unclassified  level  when  unkeyed.  Currently,  there  are  no  technology  standards 
identified  for  encrypted  storage  functions. 

3.6  Operator  Oriented  Processing  Functions 

This  part  of  the  airborne  reconnaissance  functional  reference  model  (color  coded 
purple  in  Figure  3-1)  refers  to  the  functions  provided  in  operator  workstations, 
databases,  servers,  and  product  libraries.  In  general,  these  processing  functions  are 
those  which  are  ordinarily  implemented  in  software  application  programs  hosted 
on  general  purpose  computer  equipment  (e.g.,  COTS  workstations  and  associated 
peripherals).  Therefore,  most  of  the  standards  lead  to  “open  systems”  by  guiding 
the  design  of  the  underlying  software  operating  environment.  In  modem  design 
practice,  these  standards  are  collectively  referred  to  as  “information  technology” 
(IT)  standards  which  are  the  primary  subject  of  most  technical  architectures  (e.g., 
IEEE  POSIX  and  DoD  JTA). 

The  technical  reference  model  and  IT  standards  presented  later  in  Section  4  apply 
specifically  to  the  operator  oriented  processing  functions  described  in  this  section. 
In  addition,  specific  technology  standards  that  should  be  applied,  such  as  critical 
common  software  applications  or  hardware-oriented  standards,  are  identified  in 
this  section. 

3.6.1  Operator  Workstations 

Standards  for  this  functional  area  are: 

•  Refer  to  Section  4 

Operator  workstations  can  be  located  on-board  the  airborne  reconnaissance 
platform  or  in  associated  ground/surface  systems.  Workstation  functions  are 
highly  reconfigurable  through  software-only  changes  (e.g.,  configuration  loads  for 
different  mission  requirements)  and,  therefore,  allocations  of  specific  functions 
over  a  number  of  distributed  workstations  can  be  determined  by  the  system 
users/administrators. 

All  functions  available  to  the  users/operators  are  accessible  through  the  human- 
computer  interface  (HCI)  implemented  at  the  operator  workstation.  Workstations 
host  application  programs  locally  that  provide  specific  mission  functions,  such  as 
data  processing  and  intelligence  analysis  tools,  but  they  also  host  various  software 
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clients  that  provide  access  to  programs  and  functions  hosted  on  other  distributed 
systems.  The  choice  of  where  specific  software  actually  resides  is,  and  should 
remain,  strictly  a  system  design  trade.  Through  the  selection  of  appropriate  IT 
standards,  the  technical  architecture  strives  to  enable  independence  of  application 
software  from  the  underlying  hardware  infrastructure.  The  rapid  growth  in 
computer  technology  and  effective  IT  standards  is  finally  beginning  to  show  some 
progress  towards  this  ultimate  goal. 

The  general  functions  available  to  the  users/operators  through  the  operator 
workstations  include  the  following: 

•  System  Planning  and  Control  Functions  described  in  Section  3.8 

•  SIGINT,  IMINT,  and  MASINT  sensor  control  functions  described  in 
section  3. 2. 1.2 

•  High  Performance  Processing  Functions  described  in  Section  3.5 

•  SIGINT,  IMINT,  and  MASINT  analysis/exploitation  and  exploitation 
management  functions 

•  All  source  analysis  and  data  fusion/correlation  functions 

•  Multi-INT  and  multi-platform  cross-cueing  functions 

•  Communications  and  network  management  functions 

•  System  administration  and  management  functions 

There  are  no  specific  technology  standards  that  apply  to  operator  workstations 
other  than  the  IT  standards  identified  in  Section  4. 

3.6.2  Database  Functions 

Standards  for  this  functional  area  are: 

•  None 

The  database  functions  in  the  airborne  reconnaissance  FRM  apply  to  storing, 
indexing,  linking,  managing,  maintaining,  and  accessing  reference  information 
used  throughout  the  airborne  reconnaissance  system  (i.e.,  by  various  functions 
defined  in  the  overall  FRM).  A  representative  list  of  the  types  of  information 
required  in  the  total  system  is  given  in  Section  3.8.2,  Mission  Planning  Functions 
and  Interfaces.  Although  this  is  only  one  of  the  functional  areas,  it  requires  a 
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wealth  of  information  to  support  the  required  functions,  and  the  same  information 
is  also  needed  by  many  other  system  functions.  The  database  functions  serve  to 
make  this  information  available  to  all  functions  with  no  duplication  and, 
therefore,  simplifies  database  management  procedures. 

Applicable  IT  standards  for  the  database  functions  are  identified  in  Section  4  of 
this  document. 

3.6.3  Server  Functions 

Standards  for  this  functional  area  are: 

•  Imagery  Exploitation  Support  System  (IESS) 

Server  functions  refer  to  the  various  subsystems  supporting  the  overall  system 
operations.  Examples  include  communications  servers  (e.g.,  for  formatted 
message  traffic)  and  other  software  applications  not  hosted  directly  on  the 
workstations  such  as  the  Imagery  Exploitation  Support  System  (IESS).  The  IESS 
“host”  is  considered  a  server  function,  and  the  specific  capabilities  provided  for 
image  analysts  will  be  accessible  through  client  software  running  on  their 
workstations.  IESS  provides  imagery  exploitation  management  functions  and  is 
the  designated  “standard”  to  be  used  in  imagery  ground/surface  systems.  No  other 
standardized  servers  have  been  designated  for  airborne  reconnaissance  systems. 

3.6.4  Product  Library  Functions 

Standards  for  this  functional  area  are: 

•  Image  Product  Archive  (IP A) 

•  Image  Product  Library  (IPL)  (emerging) 

The  primary  function  for  product  libraries  is  to  maintain  a  complete  set  of  all 
reconnaissance  products  produced  (in  a  given  system)  and  make  them  available  to 
all  potential  users  on  a  “pull”  or  “smart  push”  basis.*  Although  the  products  may 


“Pull”  refers  to  capabilities  where  users  can  query  and/or  browse  the  product  library  and  download  selected 
products.  “Smart  push”  is  the  case  where  a  user  defines  a  specific  profile  of  interest  and  the  product  library 
automatically  sends  matching  products  to  that  user  when  they  are  put  in  the  library.  Emerging  technology, 
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include  conventional  formatted  message  reports,  product  libraries  are  most  useful 
for  disseminating  newer  “specialized”  products  such  as  video  and  audio  clips, 
imagery,  graphics,  multi-media,  and  hypertext  products  like  those  available  on  the 
Internet.  Dissemination  of  these  products  and  access  to  the  product  libraries  will 
be  through  the  Internet  protocol  router  networks  -  NIPRNET,  SIPRNET,  and 
JWICS  -  as  described  in  Section  3.7.2,  Operator  Reporting  Functions. 

Metadata  is  probably  the  single  most  important  consideration  for  designing 
effective  product  libraries.  Metadata  is  essentially  data  about  data.  It  consists  of 
key  elements  of  information  that  serve  to  completely  describe  and  uniquely 
identify  the  product.  When  users  search  for  specific  information,  their  search  is 
usually  performed  against  the  metadata,  not  against  the  products  themselves.  For 
example,  rather  than  viewing  massive  volumes  of  digital  products,  users  would 
perform  a  query  against  the  metadata  to  identify  a  small  number  of  specific 
products  of  interest.  These  could  then  be  viewed  to  select  the  one  or  two  which 
could  be  used  to  satisfy  the  particular  need. 

The  imagery  community’s  IPA  (to  be  replaced  by  the  emerging  IPL)  is  the  only 
current  technology  standard  for  product  library  functionality  and  will  be  used  in 
airborne  reconnaissance  imagery  ground/surface  systems.  IPLs  will  contain 
metadata  in  accordance  with  the  CIO’s  Standards  Profile  for  Imagery  Access  and 
the  Profiles  for  Imagery  Archive  Extensions.  IPLs  will  also  comply  with  the 
CIO’s  Standards  Profile  for  Imagery  Dissemination. 

3.7  Reporting  and  Connectivity  Functions 

Reporting  and  connectivity  functions,  color  coded  yellow  in  the  FRM  diagram, 
provide  the  communications  pathways  and  protocols  required  to  integrate 
airborne  reconnaissance  systems  with  the  “rest  of  the  world.”  The  four  types  of 
interfaces  and  multi-level  guard  functions  are  described  in  the  following 
subsections. 

3.7.1  Direct  Reporting  Functions 

Standards  for  this  functional  area  are: 


such  as  intelligent  agents,  will  soon  enable  “smart  pull”  where  the  software  agent  automates  the 
information  discovery  and  retrieval  process  on  behalf  of  the  user. 
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•  The  J -Series  Family  of  TDLs  (DoD  JTA  Section  4.2. 4. 2.1) 

•  IBS 

•  JBS/GBS 

The  direct  reporting  interface  provides  the  required  pathway(s)  to  disseminate 
intelligence  data  directly  to  the  warfighters  or  “shooters.”  The  specific 
products/reports  disseminated  through  this  interface  will  generally  be 
automatically  generated.  This  pathway  also  allows  the  airborne  reconnaissance 
system  to  receive  direct  reporting  from  other  airborne  intelligence,  surveillance, 
and  reconnaissance  (ISR)  systems  (e.g.,  to  facilitate  cross-platform  cueing). 

Airborne  reconnaissance  systems  will  support  the  J-Series  family  of  Tactical  Data 
Links  (TDLs),  the  Integrated  Broadcast  System,  and  the  Joint  Broadcast  System 
(JBS)  as  described  in  the  following  paragraphs. 

The  J-Series  family  of  TDLs  allow  information  exchange  using  common  data 
element  structures  and  message  formats  which  support  time  critical  information. 
The  family  consists  of  Link  16,  Link  22,  and  the  Variable  Message  Format 
(VMF)  and  interoperability  is  achieved  through  use  of  J-Series  Family  messages 
and  data  elements.  The  Link  16  tactical  data  link  is  a  secure,  high  capacity,  jam 
resistant  time  division  multiple  access  (TDMA)  data  link  which  is  implemented 
with  the  Joint  Tactical  Information  Distribution  System  (JTIDS)  and  Multi¬ 
functional  Information  Distribution  System  (MIDS)  transceiver  suites.  Applicable 
standards  for  the  ARITA  are  cited  in  the  following  JTA  Sections:  3.2. 3.2.5, 

3.3. 3.2,  4.2.4.2.1,  and  4.3.4. 

IBS  is  a  migration  system  selected  by  the  DoD  to  merge  several  legacy  UHF 
broadcast  systems  into  a  common  implementation.  IBS  will  be  a  single  broadcast 
dissemination  architecture  based  on  a  single  receiver  family  (i.e.,  the  Joint 
Tactical  Terminal).  The  Military  Communications  Electronics  Board  (MCEB) 
directed  that  the  Navy  assume  executive  oversight,  the  Army  take  the  lead  for 
tactical  terminal  migration,  and  the  Air  Force  take  the  lead  for  broadcast 
migration.  By  the  objective  year  FY2000,  IBS  will  route  low  data  rate 
transmissions  to  non-GBS  satellites,  defer  high  data  rate  transmissions  (e.g., 
imagery)  to  GBS,  and  provide  additional  capability  for  interactive  two-way  line- 
of-sight  communications. 

The  Joint  Broadcast  Service  (JBS)  is  the  first  phase  of  the  Global  Broadcast 
System  (GBS)  and  was  made  operational  primarily  to  support  immediate 
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operations  in  Bosnia.  JBS  is  a  commercial  SATCOM  service  based  on 
commercial  television  Direct  Broadcast  Service  (DBS)  technology.  The  JBS  was 
implemented  as  an  element  of  the  Predator  UAV  communications  architecture, 
specifically  for  the  dissemination  of  EO  and  IR  video  sensor  information 
(including  audio  annotation/narration).  In  this  implementation,  the 
processed/exploited  video  information  is  relayed  from  the  UAV  ground  station 
via  T-3  transoceanic  cable  to  the  JBS  injection  site  located  at  the  Naval  Research 
Laboratory  (NRL),  from  where  it  is  transmitted  to  an  Atlantic  Ocean  Region 
(AOR)  to  JBS  receivers. 

The  message  format  standards  for  direct  reporting  are  cited  in  the  JTA: 

•  Section  4.2.4.2.1  Bit  Oriented  Data 

•  Section  42.4.2.2  U.S.  Message  Text  Format  (Character  Oriented  Data) 

•  Section  4.3.4  Information  Standards  (emerging) 

3.7.2  Operator  Reporting  Functions 

Standards  for  this  functional  area  are: 

•  References  to  the  DoD  JTA  will  be  included  in  a  future  version  of  the 
ARITA. 

Operator  reporting  includes  dissemination  of  formatted  message  traffic,  imagery, 
imagery  products,  database  transaction  updates,  and  graphical  situation  display 
data.  In  general,  these  products  are  widely  disseminated  through  the  DoD 
communications  infrastructure  which  includes  the  following: 

•  NIPRNET  —  Non-secure  Internet  Protocol  Router  Network;  replaces 
the  unclassified  subnet  of  the  Defense  Data  Network  (DDN) 

•  SIPRNET  —  Secure  Internet  Protocol  Router  Network;  replaces  the 
collateral  secret  subnet  of  the  DDN 

•  JWICS  —  Joint  Worldwide  Intelligence  Communications  System; 
replaces  the  TS/SCI  subnet  of  the  DDN 

•  Plain  Old  Telephone  System  (POTS)  —  includes  commercial  analog 
and  digital  circuits,  including  circuit-switched  and  packet-switched 
technology 
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The  Internet  protocol  router  networks  -  NIPRNET,  SIPRNET,  and  JWICS  - 
provide  worldwide  communications  services  for  authorized  users.  General 
services  include  electronic  mail,  file  transfer,  and  remote  terminal  functions. 
Additional  services  are  provided  by  specific  open  systems  software  applications 
which  typically  offer  client/server  functions  through  the  network  for  a  large 
population  of  users.  Access  to  the  Internet  protocol  router  networks  from  within 
airborne  reconnaissance  systems  may  be  provided  either  directly  (e.g.,  when  a 
ground/surface  system  is  located  at  a  major  operational  base  and  can  be  connected 
to  a  local  node)  or  through  other  tactical  data  networks  and/or  satellite 
communications  links  (e.g.,  when  a  ground/surface  system  is  deployed  and  linked 
back  to  its  home  node). 

Intelink  may  become  the  preferred  service  for  disseminating  airborne 
reconnaissance  products.  It  uses  COTS  software  to  provide  Internet-like  (browser) 
services  over  JWICS  and  SIPRNET.  Authorized  users  can  use  the  service  to 
access  information  on  any  server  in  the  network.  That  is,  external  users  can  access 
information  contained  in  airborne  reconnaissance  systems,  and  internal  users  can 
access  information  on  external  servers.  Although  Intelink  is  fairly  easy  to  use 
already,  more  robust  information  discovery  and  retrieval  tools  will  be  available  to 
Intelink  users  as  the  Internet  information  technology  continues  its  explosive 
growth. 

Many  airborne  reconnaissance  products  are  disseminated  as  formatted  AUTODIN 
messages  in  today’s  systems.  This  method  of  dissemination  will  continue  to  be 
used  as  appropriate  for  disseminating  USMTF  messages.  The  Defense  Message 
Service  (DMS)  is  another  service  which  rides  over  the  Internet  protocol  router 
networks  and  will  replace  AUTODIN. 

The  CIO’s  Image  Product  Library  (IPL)  will  be  another  primary  means  for 
dissemination  of  airborne  reconnaissance  imagery  and  imagery-derived  products. 
These  libraries  are  part  of  the  CIO’s  A3I  program  to  provide  an  open  architecture 
for  the  widest  possible  imagery  access  and  dissemination.  Using  IPL  client 
software,  external  users  can  access  airborne  reconnaissance  products  (stored  in 
national,  regional,  and  command  level  libraries)  through  the  internet  protocol 
router  networks  and  tactical  data  circuits  (e.g.,  ship-to-shore).  Internal  users  can 
access  products  on  other  servers.  IPL  client  software  will  be  available  on  Joint 
Deployable  Intelligence  Support  System  (JDISS),  Global  Command  and  Control 
System  (GCCS),  and  other  workstations  and  integrated  with  Intelink  client 
software  for  even  wider  use. 
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3.7.3  Command  and  Control  Interface  Functions 

Standards  for  this  functional  area  are: 

•  See  ARITA  Sections  3. 7.2  and  3.8 

The  C2  interface  functions  provide  the  primary  means  for  warfighter  command 
and  control  over  airborne  reconnaissance  systems.  This  pathway  provides  the 
various  communications  services  for  passing  information  such  as  command  and 
control  messages,  mission  tasking,  intelligence  database  updates,  etc.  The 
networks,  services,  and  technology  standards  are  the  same  as  those  used  for  the 
operator  oriented  reporting  functions  described  in  the  previous  section.  However, 
the  information  and  specific  data  formats  communicated  are  different. 

Additional  C2  interface  functions  for  airborne  reconnaissance  are  with  collection 
management  systems,  mission  planning  systems,  and  mission  control  systems. 
Detail  on  these  functions  is  given  in  Section  3.8,  System  Planning  and  Control 
Functions. 

3.7.4  Reach  Back  /  Reach  Forward  Functions 

Standards  for  this  functional  area  are: 

•  None 

The  reach  back  /  reach  forward  functions  provide  the  interfaces  required  for 
near-real-time  integration  with  other  intelligence  community  systems  and  to 
support  split-base  operations.  Reach  back  generally  refers  to  an  operation  where 
airborne  reconnaissance  sensor  data  is  passed  back  to  supporting  site  facilities  for 
processing  and/or  exploitation/analysis.  This  is  required  in  cases  where  the 
airborne  asset  does  not  have  the  capacity  or  capability  to  support 
analysis/exploitation  of  sensor  data  on-board.  Reach  forward  generally  refers  to 
capabilities  for  data  from  supporting  intelligence  centers  to  be  forwarded  to  the 
airborne  reconnaissance  system  for  relay,  exploitation,  cross-system  cueing,  data 
correlation,  or  other  intelligence  functions. 

High  data  rate  point-to-point  communications  circuits  are  used  to  support  the 
reach  back  /  reach  forward  functions.  These  functions  can  be  implemented  on 
commercial  circuits  (e.g.,  INMARSAT,  Intelsat,  PANAMSAT,  etc.)  or  on 
military  assets  (e.g.,  Defense  Secure  Communications  System  (DSCS),  Trojan 
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Spirit).  Data  communications  protocol  standards  are  selected  on  a  case-by-case 
basis  tailored  to  the  communications  circuits  available,  airborne  reconnaissance 
systems  involved,  and  mission  requirements.  Minimum  data  link  requirements  for 
SIGINT  are  192  kilobits  per  second  return  link  and  64  kilobits  per  second 
command  link.  IMINT  missions  often  require  tens  to  hundreds  of  megabits  per 
second  on  the  return  link,  and  the  data  rate  for  MASINT  missions  are  still  being 
worked  but  will  not  exceed  IMINT  requirements. 

3.7.5  Multi-Level  Guard  Functions 

The  multi-level  guard  functions  provide  appropriate  security  protection/filters  that 
securely  implement  and  enforce  the  required  airborne  reconnaissance  system 
security  perimeter.  These  functions  include  firewalls,  security  guards,  and  link 
encryption  as  appropriate.  Standards  in  this  area  will  be  addressed  in  a  future 
version  of  the  ARITA. 

3.8  System  Planning  and  Control  Functions 

The  ARITA  defines  three  general  areas  for  dealing  with  planning  and  control 
functions  and  related  standards.  These  are: 

•  Collection  management, 

•  Mission  planning,  and 

•  Mission  control. 

Collection  management  is  a  process  that  is  performed  by  a  Collection 
Management  Authority  (CMA)  who  uses  a  specific  collection  management 
system.  The  interfaces  with  those  systems  are  covered  in  Section  3.8.1  below. 
Mission  planning  is  a  process  that  may  be  performed  within  an  airborne 
reconnaissance  system  or  it  may  be  performed  externally.  These  functions  and 
interfaces  are  covered  in  Section  3.8.2.  Mission  control  is  a  process  which  deals 
with  execution  of  specific  reconnaissance  missions  and  is  therefore  an  integral 
part  of  airborne  reconnaissance  systems  (i.e.,  internal  functions).  The  mission 
control  functions  and  associated  technology  standards  are  covered  in 
Section  3.8.3. 
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3.8.1  Collection  Management  Interfaces 

Standards  for  this  functional  area  are: 

•  Form  1684  (de  facto) 

•  RMS  Aircraft  Tasking  Message  (emerging) 

There  are  currently  two  basic  procedures  for  tasking  airborne  reconnaissance 
missions.  Normal  peacetime  operations  are  under  Sensitive  Reconnaissance 
Operations  (SRO)  rules  and  undergo  rigorous  and  time  intensive  tasking  and 
planning  procedures.  These  procedures  are  detailed  in  CJCSI  3250.01,  02,  and  03 
and  the  various  theater  reconnaissance  operations  directives.  These  will  not  be 
discussed  here.  Contingency  and  wartime  reconnaissance  missions  follow  the 
same  general  procedures  as  SRO  missions,  except  that  the  planning,  tasking  and 
execution  focus  is  dictated  by  the  theater  or  JFCC  operations  orders.  Collection 
requirements  are  generated  by  warfighters  and  then  allocated  to  collectors  by  the 
CMA.  The  CMA  typically  uses  a  system  such  as  the  JCMT  to  provide  an 
overview  of  the  requirements  database.  Next  JCMT  conducts  a  feasibility 
assessment  considering  all  classes  of  collection  assets,  ranging  from  ground  to 
airborne  to  space  collectors.  Once  a  particular  collector  is  deemed  appropriate  and 
able  to  conduct  the  operation,  JCMT  will  perform  a  more  detailed  feasibility 
analysis  using  a  model  of  the  reconnaissance  system  and  sensors.  With  these 
results,  the  CMA  will  task  a  collection  system;  this  requires  coordination  with  the 
Air  Operations  Center  (AOC)  for  the  scheduling  of  reconnaissance  missions. 
Actual  tasking  then  flows  to  the  operational  unit  potentially  twice:  the  mission 
route  and  timing  sequence  is  generated  as  an  integrated  part  of  the  Air  Tasking 
Order  (ATO)  and  approved  by  the  AOC  while  specific  sensor  tasking  is  generated 
directly  by  the  collection  management  system  (in  the  form  of  sensor  tasking 
messages  such  as  the  Form  1684  for  imagery).  The  CMA’s  collection 
management  system  provides  the  reconnaissance  feedback  to  the  warfighters  who 
originated  the  requests  for  information.  The  notional  tasking  flow  is  depicted  in 
the  following  diagram. 
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Figure  3-7:  Notional  Flow  for  Collection  and  Mission  Tasking 

The  collection  tasking  and  feedback  messages  form  the  key  interface  functions  for 
airborne  reconnaissance  systems.  These  messages  will  vary  depending  on  which 
collection  management  system  the  CMA  is  using,  and  what  type  of  collection  is 
being  tasked  (i.e.,  SIGINT,  IMINT,  or  MASINT).  The  interface  between  airborne 
reconnaissance  and  collection  management  systems  is  effected  through  the 
Command  and  Control  Interface  Functions  (Section  3.7.3). 

IMINT  collection  tasking  has  long  been  dependent  on  a  machine  readable 
message  format  -  the  Form  1684,  which  was  eliminated  in  November  1994  by 
DIA/CL  (the  collection  management  authority).  However,  systems  such  as  CARS 
and  ETRAC,  functioning  as  U-2  ground  stations,  continued  to  use  this  message 
format  since  there  is  still  no  replacement.  Other  airborne  reconnaissance  systems 
are  equally  dependent  on  a  standard  machine-readable  tasking  message.  In  some 
systems,  collection  tasking  is  not  automated  and  telephone  conversations  (voice) 
may  be  the  sole  means  for  receiving  and  coordinating  tasking  from  the  CMA. 

SIGINT  collection  tasking  is  highly  structured  and  follows  priorities  similar  to 
those  expressed  in  the  National  SIGINT  Requirements  Listing  (NSRL).  The 
collection  operator  is  provided  with  a  prioritized  listing  of  collection  needs  with 
detailed  descriptions  of  known  operating  procedures  and  intelligence  needs.  From 
this  prioritized  listing,  the  SIGINT  collection  system  managers  allocate  resources 
to  meet  tailored  mission  needs.  For  airborne  collection,  SIGINT  Numerical 
Tasking  Requirements  (SNUTRs)  usually  detail  a  prioritized  set  of  target  signals 
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(and  specific  collection  and/or  processing  requirements)  for  any  number  of 
collection  scenarios. 

Collection  tasking  for  MASINT  systems  is  limited  to  selecting  airborne  platforms 
with  future  areas  not  yet  fully  defined  for  airborne  reconnaissance  systems. 

An  RMS  Aircraft  Tasking  Message  is  proposed  to  come  into  use  by  RMS  during 
the  1999  to  2000  time  frame.  JCMT  also  plans  to  use  the  new  RMS  Aircraft 
Tasking  Message  format  for  imagery  tasking.  This  format  could  be  adapted  for 
SIGINT  and  MASINT,  thereby  making  this  message  effective  for  multi  source 
tasking.  This  would  require  coordination  among  DIA,  NRO,  CIO,  NS  A,  DARO, 
and  CMO  etc.  With  this  standard  a  commander  at  any  echelon  can  forward  his 
collection  request  to  the  appropriate  collection  management  office  for  validation. 
The  CMA  will  be  able  to  forward  the  request  for  national  satisfaction  or  route  the 
request  to  the  appropriate  tactical  airborne  collector.  Organic  tactical  collection 
assets  will  continue  to  be  tasked  by  their  tactical  commanders  without  change 
from  current  practice. 

Airborne  reconnaissance  systems  must  provide  feedback  to  the  CMA  who,  in 
turn,  provides  status  to  the  warfighters.  This  includes  the  following  information: 

•  When  collection  requirements  were  accepted 

•  Which  collection  mission  was  tasked 

•  When  the  collection  mission  was  completed 

•  Which  ground/surface  system  was  tasked 

•  When  the  reconnaissance  product  will  be  delivered 

•  How  the  reconnaissance  product  will  be  delivered 

3.8.2  Mission  Planning  Functions  and  Interfaces 

Standards  for  this  functional  area  are: 

•  None 

In  general,  all  of  the  following  high-level  “mission  planning”  functions  have  to  be 
accomplished  for  any  airborne  reconnaissance  mission,  whether  it  be  for  UAVs  or 
manned  platforms: 
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•  Route  planning  (navigation  aids,  radar  predictions,  way  points,  turn 
points,  flight  plans,  air  space  deconfliction,  refueling  points,  etc.) 

•  Calculations  for  takeoff  and  landing,  fuel  consumption,  etc. 

•  Maneuvers  and  tactics  for  target  penetration  and  threat  avoidance 
(SAM/ AAA  lethality,  detection  avoidance,  radar  cross  section,  etc.) 

•  Planning  for  escape  and  evasion  (including  preplanned  search  and 
rescue  operations) 

•  Communications  planning  (frequency  allocations  for  data  links  and 
radios,  link  acquisition  and  tracking,  IFF  initialization,  etc.) 

•  Collection  strategy  and  sensor  planning  (time  on  target,  sensor  and 
mode  selection,  acquisition  parameters,  etc.) 

Not  all  airborne  reconnaissance  systems  have  their  own  integral  mission  planning 
capabilities.  In  some  cases,  the  planning  functions  are  performed  externally  by 
flight  operations  personnel  (e.g.,  flight  crew),  and  the  detailed  plans  are  then 
passed  to  the  associated  ground/surface  system  so  they  can  plan  for  the 
subsequent  processing,  exploitation,  and  reporting.  In  other  cases,  processing, 
exploitation,  and  reporting  functions  are  performed  on-board  the  platform,  so 
passing  the  detailed  mission  plans  is  not  a  necessary  interface. 

AFMSS  and  TAMPS  are  the  mainstream  mission  planning  systems  currently  used 
with  many  types  of  aircraft.  Both  AFMSS  and  TAMPS  have  the  requisite 
functions  and  capabilities  needed  to  perform  most  of  the  mission  planning 
functions  for  airborne  reconnaissance  platforms,  but  they  do  not  have  capabilities 
for  collection  strategy  and  sensor  planning,  nor  do  they  have  the  platform-specific 
parametric  data,  performance  models,  etc.  Nevertheless,  AFMSS  and  TAMPS  are 
the  preferred  technology  standards  for  meeting  airborne  reconnaissance  mission 
planning  needs.  Using  a  DoD  standardized  capability,  even  a  de  facto  one,  is 
preferable  to  proliferating  custom-built,  unique  subsystems  just  for  airborne 
reconnaissance. 

Mission  planning  requires  a  wealth  of  information,  some  of  which  is  listed  below. 
Acquiring  and  managing  this  information  in  a  “standardized”  mission  planning 
system  is  (arguably)  the  prime  benefit  realized  by  picking  a  standardized 
system/technology.  In  addition,  much  of  the  information  can  and  should  be  shared 
with  other  functional  areas,  although  this  is  too  often  not  the  case  in  current 
systems.  In  the  context  of  the  airborne  reconnaissance  FRM,  the  information 
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should  be  stored  and  managed  in  the  database  functional  area  described  in 
Section  3.6.2.  Examples  follow: 

•  Operations  and  tasking  messages/data  such  as  air  tasking  orders, 
airspace  control  orders,  special  instructions,  airlift  mission  schedules, 
etc. 

•  Detailed  meteorological  data  and  weather  forecasts 

•  Digital  Aeronautical  Flight  Information  File  (DAFIF)  and  installations 
data 

•  Intelligence  data  (ostensibly  in  DIA  MIIDS/IDB  format)  including: 

-  Orders  of  Battle  including  Air,  Electronic,  Missile  (fixed), 
Tactical  (mobile),  Naval,  and  Ground 

-  Data  correlated  and  fused  from  multiple  theater  sources  (e.g., 
from  JIC/JAC) 

-  Near-real-time  intelligence  from  broadcast  or  tactical  data  links 

-  Local  intelligence  from  post  mission  analyses  and  briefings 

•  Aircraft/platform  performance  models,  parametric  data,  and  radar 
cross  section  data  (e.g.,  from  the  Technical  Orders  and  manuals) 

•  Sensor  models  and  parametric  models 

•  Threat  models  and  parametric  data 

•  Mapping,  cartography,  and  geodesy  data  (e.g.,  from  DMA) 

-  Global  Navigation  Charts,  1 :5, 000, 000 

-  Jet  Navigational  Charts,  1 :2, 000, 000 

-  Operational  Navigational  Charts,  1 : 1 ,000,000 

-  Tactical  Pilotage  Charts,  1 :500,000 

-  Joint  Operations  Graphics- Air,  1 :250,000 

-  Topographic  Line  Maps,  1 :50,000 

-  City  Graphic  (variable  scales  from  1 :5,000  to  1 : 1 5,000) 

-  Digital  Terrain  Elevation  Data  (DTED) 

—  Probabilistic  Vertical  Obstruction  Data  (PVOD) 
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-  Digital  Features  Analysis  Data  (DFAD)  Level  1 

-  Vector  Smart  Map  (VMAP) 

-  Digital  Nautical  Chart 

-  Digital  Bathymetric  Database 

-  Navigation  Information  Network 

-  Tactical  Terrain  Data 

-  Digital  Chart  of  the  World  (DCW) 

-  Vector  Product  Family  (VMAPO,  VMAP1) 

-  Urban  Vector  Map 

-  Electronic  Chart  Updating  Manuals  (ECHUMs) 

-  Digital  Point  Positioning  Database  (DPPDB) 

•  Reference  imagery  including  SPOT,  LANDSAT,  and  target  imagery 

The  interfaces  required  for  mission  planning  functions  vary  depending  on  specific 
system  operational  requirements  and  mission  needs.  For  example,  systems 
operated  by  the  USAF  will  receive  intelligence  data  from  the  unit-level  Combat 
Information  System  (CIS),  whereas  Special  Operations  Forces  will  be  served  by 
SOCRATES  (their  intelligence  system),  and  the  Army  will  generally  rely  on  their 
All  Source  Analysis  System  (ASAS).  Regardless  of  the  source  of  the  data,  it  will 
generally  be  received  in  airborne  reconnaissance  systems  through  the  Command 
and  Control  Interface  Functions  described  in  Section  3.7.3  or  via  bulk  digital 
media  such  as  magnetic  tape  and  CD-ROM. 

3.8.3  Mission  Control  Functions 

Standards  for  this  functional  area  are: 

•  None 

Mission  control  functions  provide  for  real-time  and  near-real-time  control  of  the 
platform,  sensor  suite,  and  communications  subsystems  during  the  execution  of 
reconnaissance  missions.  This  functional  component  of  the  FRM  refers  to  the 
control  functions  implemented  in  ground/surface  subsystems.  Real-time  control 
functions  in  the  airborne  components  are  covered  in  the  System  Processing  and 
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Control  Functions  part  of  the  FRM  described  in  Section  3.5.2.  Obviously,  there  is 
an  interface  between  these  two  functional  components  which  is  implemented 
through  the  data  link  (Section  3.4.4). 

The  three  highest-level  types  of  mission  control  functions  are  listed  below.  Note 
that  different  implementations  may  provide  none  of  the  functions,  any 
combination,  or  all  of  the  mission  control  capabilities  depending  on  specific 
systems  employed,  their  configuration,  and  mission  operational  requirements. 

•  Remote  piloting  functions  and  telemetry  data; 

•  Remote  sensor  control  functions;  and 

•  Dynamic  retasking  functions. 

In  the  case  where  a  UAV  is  remotely  piloted,  telemetry  data  is  transmitted  to  the 
ground/surface  system  and  piloting  commands  are  transmitted  to  the  vehicle  via 
the  data  link  in  real-time.  The  telemetry  data  essentially  provides  the  same  data 
that  would  otherwise  be  displayed  to  a  cockpit  pilot,  but  it  is  processed  and 
displayed  on  ground-based  equipment.  As  an  aide  to  the  ground-based  “pilot,” 
telemetry  data  also  includes  real-time  video  (e.g.,  in  the  visible  part  of  the 
spectrum).  The  remote  piloting  functions  are  also  used  to  facilitate  take-off  and 
landing  for  UAVs  that  may  otherwise  operate  autonomously  by  executing 
programmed  flight  and  sensor  operations  plans.  Currently  there  are  no  standards 
for  remote  piloting  and  telemetry  data  interfaces. 

Remote  sensor  control  functions  serve  to  extend  real-time,  direct  control  of  the 
collection  equipment  to  operators  stationed  in  ground/surface  systems.  Remote 
commands  may  include,  for  example,  tuning  receivers,  aiming  directional 
antenna,  changing  sensor  modes,  pointing  cameras,  adjusting  focal  length  and 
exposure,  setting  on-board  processing  parameters,  and  a  host  of  other  operator- 
controlled  functions.  Currently,  there  are  no  standards  for  remote  commanding 
functions. 

However,  a  standardized  command  set  for  each  major  type  of  sensor  (e.g.,  for 
tuners,  cameras,  SAR,  MTI,  spectral,  video,  etc.)  would  likely  facilitate  a  much 
higher  degree  of  interoperability  among  systems  (e.g.,  a  step  towards  enabling 
common  ground/surface  systems  to  interoperate  with  multiple  platforms). 
Standardized  command  sets  would  also  enable  the  manufacture  of 
interchangeable  sensors  (e.g.,  same  form,  fit  and  function  components  from 
multiple  vendors). 
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Dynamic  retasking  functions  enable  reconnaissance  operations  to  be  changed  in 
near-real-time  by  designated  users/operators.  Changes  may  affect  the  platform, 
such  as  navigating  to  a  new  track  (flight  path),  or  they  may  affect  the  sensor 
suites,  such  as  switching  SAR  modes  or  switching  from  SIGINT  to  imagery 
collection.  Dynamic  retasking  increases  mission  effectiveness  by  enabling 
reasonably  rapid  response  to  unexpected  events  such  as  changes  in  weather,  tip- 
offs  from  other  collection  systems  (e.g.,  national),  cross-cueing  among  multiple 
interconnected  platforms,  and  changes  in  ISR  needs.  Retasking  generally  involves 
preparing  revised  mission  and  sensor  plans  in  near-real-time  and  “up  loading”  the 
new  information  to  the  affected  platform.  Currently,  in  the  case  of  manned 
platforms,  the  retasking  is  usually  communicated  to  the  Mission  Commander  via 
voice  or  message.  In  the  future,  as  for  UAVs,  retasking  will  involve  transmitting 
updated  data  to  the  platform  electronics  and  sensor  subsystems  (including 
reinitializing  the  navigation  systems).  Functions  and  standards  for  preparing 
mission  and  sensor  plans  are  discussed  in  Section  3.8.2  above. 

3.9  Summary  of  Technology  Standards  for  the  FRM 

The  specific  technology  standards  cited  for  the  various  functional  areas  of  the 
FRM  are  summarized  in  the  following  table.  In  addition  to  listing  the  existing 
standards,  the  table  includes  the  areas  which  were  specifically  identified  as  key 
areas  where  new  standards  would  be  particularly  beneficial. 
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Table  3-1:  Summary  of  Technology  Standards 


Section  Title 


Existing  Standard(s) 


Standard(s)  Needed 


3.2. 1.2 


Common  Front-End 
Functions 


Sensor/Platform 
Integration  Mechanics 


Sensor  Control  Functions 


Special  Pre-Processing 
Functions 


SIGINT  Front-End 
Functions 


3.2.2.1  RF  Distribution 


Low  and  High  Band 
Tuners 


3. 2.2.3  Set-On  Receivers 


IF  Distribution 


MIL-STD-704E 
(Prime  Power) 


Standardized  command  set 


High  rate  digital  imagery: 

•  DCRSi 

•  ANSI  ID-1 

Legacy  analog  video: 

•  VHS  and  Super  VHS 

•  Hi  8mm 

Migration  to  digital  video: 

•  Y/C  component  analog 

•  SMPTE  VITC  (timing) 

•  Dual-capable  analog/ 
SMPTE  259M  recorder 

Digital  video: 

•  SMPTE  259M 

SIGINT  recorders: 

•  AN/USH  -  28 

•  DTSR 

•  Hi  8mm 

Timing  data: 

•  IRIG-B 


500  coax  cable 


IF  distribution  via  500 
coax  cable,  frequencies  at: 

21.4  MHz 
70  MHz 
160  MHz 
1000  MHz 
5000  MHz 
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Table  3-1:  Summary  of  Technology  Standards,  continued 


Section  Title 


Existing  Standard(s) 


Standard(s)  Needed 


3 .2.2.5 


3.2.2.6 


IF  Digitizer 


Sub-Band  Tuners 


IMINT  Front-End 
Functions 


3.2.3. 1  Film  Cameras 


Electro-Optical  Sensors 


3. 2.3. 3  Infrared  Sensors 


Common  practice: 

8  to  1 1  bits/pixel 
greyscale,  24  bits/pixel 
color  (typical) 

Up  to  274  Mb/s  data  rate 
(CDL  limit) 


NTSC/RS-170  (analog) 

HDTV/MPEG-2  (digital) 

•  CCIR  601  4:2:2 

•  SMPTE  VITC 

-  SMPTE  RP173 

-  SMPTE  RP 179 

•  MPEG-2  4:2:2  profile@ 
main  level 

-  ISO  13818-1  Systems 
-ISO  13818-2  Video 
-ISO  13818-3  Audio 


Synthetic  Aperture  Radars 


Moving  Target  Indicator 
Radar 


Spectral  Sensors 


Image  Quality  Standards 


MASINT  Front-End 
Functions 


Chemical/Biological 
Weapons  Sensors 


Laser  Warning  Sensors 


Unattended  Ground 
Sensors 


Air  Sampling 


Future  standards  from 
Common  Image  Processor 


Image  interpretability 
scales  for  visible,  IR,  and 
SAR 


Image  interpretability  scale 
for  video 


Page  82 

DRAFT 


DRAFT 


Table  3-1:  Summary  of  Technology  Standards,  continued 


Existing  Stand  ard(s) 


Section 

Title 

.5 

Synthetic  Aperture  Radars 

.6 

Spectral  Sensors 

RF  Sensors 

3.3 

Navigation,  Timing,  and 
Ancillary  Data 

Networking  Functions 


3.4.1  Command  and  Control 
Network 


.2  High-Speed  Data  Flow 
Network 


Multimedia  Network 


Data  Link 


High  Performance 
Processing  Functions 


Digital  Signal  Processing 
Functions 


System  Processing  and 
Control  Functions 


Encrypted  Storage 


Operator  Oriented 
Processing  Functions 


Operator  Workstation 


Database  Functions 


Server  Functions 


Global  Positioning  System 
USNO-UTC  synchronized 
MIL-STD-1553B  bus 
IRIG-B 

SMPTE  VITC  (video) 


Ethernet  (10  Mb/s) 

Fast  Ethernet  (100  Mb/s) 
FDDI  (100  Mb/s) 
ATM/SONET  (155  Mb/s) 
Fibre  Channel  (800  Mb/s) 


Fibre  Channel 


Ethernet  (10  Mb/s) 

Fast  Ethernet  (100  Mb/s) 
FDDI  (100  Mb/s) 
ATM/SONET  (155  Mb/s) 
Fibre  Channel  (800  Mb/s) 


Common  Data  Link 


Image  compression 
algorithms:  JPEG  for  still 
imagery,  MPEG-2  for 
digital  video 


Standard(s)  Needed 


Future  standards  from 
Common  Image  Processor 


“Across-the-board”  data 
element  and  format 
standard(s) 


Future  standards  from 
Common  Image  Processor 
and  SIGINT  R&D  (e.g., 
shoe-box  size  super 
computer  technology) 


ARITA  Section  4 


ARITA  Section  4 


Image  Exploitation 
Support  System 


Standard  applications  for 
SIGINT  and  MASINT 
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4.  Airborne  Reconnaissance  Technical  Reference  Model  and 
Information  Technology  Standards 

The  airborne  reconnaissance  Technical  Reference  Model  (TRM)  provides  a 
common  framework  depicting  the  open  systems  software  environment  to  be 
followed  in  migrating  or  developing  airborne  reconnaissance  systems.  The  TRM 
was  derived  from  the  Technical  Architecture  Framework  for  Information 
Management  (TAFIM).  Information  technology  (IT)  standards  follow  the  DoD 
Joint  Technical  Architecture  (JTA)  -  Draft  Version  1.0, 12  July  1996. 

4.1  Relationship  to  the  Functional  Reference  Model 

The  FRM  (Figure  3-1)  represents  information  flow  from  an  operational  or 
functional  view,  whereas  the  TRM  represents  the  software  interactions  in 
satisfying  discrete  services  or  functions  associated  with  IT.  These 
services/functions  associated  with  IT  apply  to  various  areas  of  the  FRM, 
especially  Operator  Oriented  Processing  Functions  (purple),  High  Performance 
Processing  Functions  (orange),  Networking  Functions  (red)  Reporting  and 
Connectivity  Functions  (yellow). 

4.2  TRM  Overview 

The  TRM  shown  in  Figure  4-1  does  not  imply  any  specific  system  design;  rather, 
its  purpose  is  to  provide  the  framework  for  defining  IT  standards.  As  with  the 
TAFIM,  the  airborne  reconnaissance  TRM  is  based  on  the  POSIX  Open  System 
Reference  Model  and  includes  three  entities  and  two  classes  of  interfaces.  The 
three  entities  are  the  Application  Software  Entity,  the  Application  Platform 
Entity,  and  the  External  Environment  Entity.  The  classes  of  interfaces  are  the 
Application  Program  Interfaces  (APIs)  and  the  External  Environment 
Interfaces  (EEIs). 
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Application  Software  Entity 

“Mission  Area1’  Applications 

Mission  1 
Planning  | 

Mission  j 
Tasking  | 

Mission  j  Mission  j  Analysis  &  |  Data  }  Product 

Control  |  Processing  |  Exploitation  [Management |  Library/Archive 

|  Dissemination 

Multi-Media 

|  Communi- 
|  cations 

Common  Support  Applications 

1  Business  I  Environment  I  Database  1 
j  Processing  |  Management  j  Utilities  j 

Engineering  1 
Support  | 

Navigation  & 
Timing 

System 

Services 


Human/Computer 
Interaction  Services 


Information 

Services 


Communications 

Services 


Application 
Program 
Interface  (API) 


Application  Platform  Entity 


Software 

Engineering 

Services 

User 

Interface 

Services 

Data 
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Services 

Data 

Interchange 

Services 

Graphics 
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Graphical  User 
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Management 

Imagery  Data  j 

Vector  Data 

Session 
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Sound  Data  ( 
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Transport 
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Icons/Symbols 

Network 

Management 
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Kernel  Operations  Clock/Calendar  Shell  and  Utilities  Media  Handling 
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.■S’  5  = 

^  S  ja 

3  E  S 

o>  a  w 

w  m  q 

>. 

W 


Network 

Services 


Information 

Services 


Human/Computer  External 
Interaction  Services  Environment 
|  Interface  (EEI) 


Information 

Interchange 


External  Environment  Entities 


Figure  4-1:  Airborne  Reconnaissance  Technical  Reference  Model 
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The  Application  Software  Entity  includes  the  Intelligence  Mission  Area 
Applications  (SIGINT,  IMINT,  MASINT),  as  well  as  common  support 
applications.  The  Application  Software  Entity  resides  on  the  Application 
platform.  The  Application  Platform  Entity  provides  platform  services  and 
processing  capabilities.  The  External  Environment  includes  entities  (such  as 
operators,  removable  disks/tapes,  and  communication  pathways)  with  which  the 
application  platform  exchanges  information. 

A  description  of  each  entity  and  interface  identified  in  the  TRM  is  given  in  the 
following  subsections  together  with  identification  of  standards  selected  for 
airborne  reconnaissance  systems  (i.e.,  mandated),  and  references  to  standards 
which  are  not  yet  mature  enough  to  select  but  show  promise  for  resolving  specific 
technical  architecture  issues. 

4.3  Application  Software  Entity 

The  Application  Software  Entity  comprises  the  airborne  reconnaissance  Mission 
Area  Applications  and  Common  Support  Applications.  This  application  software 
may  be  commercial  off  the  shelf  (COTS),  government  off  the  shelf  (GOTS), 
custom-developed  software,  or  a  combination  of  these.  The  following  mandate 
applies: 

•  All  airborne  reconnaissance  developers  shall  identify  their  common 
support  applications  and  mission  area  applications.  Common  support 
and  mission  area  applications  shall  transition  to  the  DII  COE  to  the 
maximum  extent  possible. 

4.3.1  Mission  Area  Applications 

Mission  area  applications  implement  specific  end  user  requirements  (e.g.,  multi¬ 
sensor  information  processing,  control  of  real-time  systems,  decision  support, 
analysis  of  order  of  battle).  These  applications  encompass  all  software  embedded 
in  airborne  reconnaissance  and  associated  ground/surface  systems.  The  Imagery 
Exploitation  Support  System  (IESS)  is  the  only  “standardized”  mission  area 
application  identified  for  the  ARITA  to  date  (see  Section  3.6.3).  This  system  was 
selected  by  the  ISB  (with  CIO  and  DARO  concurrence)  to  be  the  migration 
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system  for  imagery  exploitation  management  functions.*  Future  applications  will 
address  the  SIGINT  and  MASINT  areas. 

4.3.2  Common  Support  Applications 

Common  support  applications  (e.g.,  message  handling,  graphics,  imagery)  can  be 
standardized  across  individual  or  multiple  mission  areas.  The  services  they 
provide  can  be  used  to  develop  mission-area-specific  applications  or  can  be  made 
available  to  the  user.  The  TAFIM  TRM  defines  six  (6)  common  support 
application  categories:  Multimedia,  Communications,  Business  Processing, 
Environment  Management,  Database  Utilities,  and  Engineering  Support.  The 
definitions  of  these  categories  are  found  in  the  TAFIM,  Volume  2,  Section  2.4.2. 
One  additional  category  has  been  added  for  the  airborne  reconnaissance  TRM: 
Navigation  and  Timing. 

•  The  imagery  community  has  identified  RULER  as  a  standardized 
common  support  application  for  imagery  processing/exploitation 
applications.  RULER  software  performs  imagery  mensuration 
calculations  using  standardized  math  models  formally  controlled  by 
the  imagery  community. 

4.4  Application  Platform  Entity 

The  Application  Platform  Entity  includes  the  standard  services  upon  which  the 
required  functionality  is  built.  The  Application  Platform  Entity  is  used  by  support 
applications  and  unique  mission  area  applications  software.  The  TAFIM  TRM 
version  3.0  defines  seven  (7)  service  areas  within  the  Application  Platform  Entity: 
Operating  System,  Software  Engineering,  User  Interface,  Data  Management,  Data 
Interchange,  Graphics,  and  Communications.  The  TAFIM  TRM  also  defines  four 
(4)  Application  Platform  cross-service  areas:  Internationalization,  Security, 
System  Management,  and  Distributed  Computing  services.  The  definitions  of 
these  services  are  found  in  the  TAFIM,  Volume  2,  Section  2.4.3  and  2.4.4 
respectively.  The  corresponding  mandates  are  provided  in  the  following 
subsections. 


Although  JCMT  and  RMS  are  also  selected  migration  systems,  they  are  not  embedded  in  airborne 
reconnaissance  systems. 
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4.4.1  Operating  System  Services 

These  core  services  are  necessary  to  operate  and  administer  a  computer  platform 
and  to  support  the  operation  of  application  software.  They  include  kernel 
operations,  shell,  and  utilities.  The  kernel  controls  access  to  information  and  the 
underlying  hardware.  These  services  are  accessed  by  applications  through  either 
the  standard  Portable  Operating  System  Interface  (POSIX)  (e.g.,  VX  Works, 
Solaris  2.3,  HP-UX  9.01)  or  WIN32  APIs.  The  standards  for  ARITA  are: 

•  Mandated:  JTA  Section  2.2. 2. 1.7,  Operating  Systems  Services 

•  Emerging:  JTA  Section  2.3.5,  Operating  Systems 

4.4.2  Software  Engineering  Services 

The  software  engineering  services  provide  system  developers  the  tools 
appropriate  to  the  development  and  maintenance  of  applications.  These  include 
programming  languages,  language  bindings  and  object  code  linking,  and 
Computer  Aided  Software  Engineering  (CASE)  environments  and  tools. 

4.4.2.1  Programming  Languages 

Language  services  provide  the  basic  syntax  and  semantic  definitions  for  use  by 
developers  to  describe  the  desired  software  function.  Ada  is  mandated  in  DoD 
Directive  3405.1.  This  directive  requires  that  Ada  be  used  for  custom  developed 
software  in  all  DoD  system  developments.  This  mandate  does  not  include 
software  that  is  developed  and  maintained  commercially.  Software  development 
will  be  based  on  Ada  95.  Ada  95  is  backward  compatible  with  Ada  83  language 
specification.  The  standards  for  ARITA  are: 

•  Mandated  when  Ada  is  used:  ISO/IEC  8652:  1995  (Ada  95),  Ada 
Reference  Manual,  Language  and  Standard  Libraries. 

•  Mandated  standard  when  C  is  used  (Ada  waiver  required):  ANSI/ISO 
9899  C  Language 

If  a  waiver  to  Ada  is  sought,  the  guidelines  documented  in  Assistant  Secretary  of 
Defense  Memorandum,  “Delegations  of  Authority  and  Clarifying  Guidance  on 
Waivers  from  the  use  of  Ada  Programming  Language,”  must  be  followed. 
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4.4.2. 2  Language  Bindings  and  Object  Linking 

Language  bindings  and  object  code  linking  provide  the  ability  for  software  to 
access  services  and  software  through  API’s  that  have  been  defined  independently 
of  the  computer  language.  Ada  bindings  will  be  used  to  provide  the  interface  to 
COTS  or  GOTS  software  that  is  developed  in  other  languages.  The  standards  for 
ARITA  are: 

•  IEEE  1003.5b:  1992:  POSIX:  Ada  Language  Interfaces  Part  1: 
Binding  for  System  API. 

•  ISO/IEC  9075:  1992:  Database  Languages-SQL  (Embedded  SQL  to 
Ada  Bindings). 

•  ISO  12227:  1994:  SQL  Ada  Module  Description  Language 

•  ISO/IEC  9593-3:  1990:  PHIGS  Language  Bindings-Part  3:  Ada 

•  ISO/IEC  9638-3:  1994:  Interface  techniques  for  dialogues  with 
graphical  devices  Computer  Graphics  Interface  (CGI)-Language 
Bindings-Part  3:  Ada 

4.4.2.3  Computer  Aided  Software  Engineering  (CASE)  Environments  and 
Tools 

CASE  provides  the  environment  and  tools,  include  systems  and  programs  that 
assist  in  the  automated  development  and  maintenance  of  systems  (hardware  and 
software).  The  standards  for  ARITA  are: 

•  ANSI/IEEE  1209-1992,  Case  Tools  and  Environment 

4.4.3  User  Interface  Services 

These  services  implement  the  Human-Computer  Interface  (HCI)  style  and  control 
how  users  interact  with  the  system.  The  ARITA  follows  the  JTA  which  mandates 
either  Common  Desktop  Environment  (CDE)  version  1 .0  based  on  X  window 
system  and  Open  System  Foundation  (OSF)  Motif  APIs,  or  the  applicable  native 
windowing  WIN32  APIs  The  standards  for  ARITA  are: 

•  Mandated:  JTA  Section  2.2.2. 1 .2,  User  Interface  Services 

•  Mandated:  JTA  Section  5.2,  HCI  Mandates 
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•  Emerging:  JTA  Section  2.3.2,  User  Interface 

•  Emerging:  JTA  Section  5.3,  HCI  Emerging  Standards 

4.4.4  Data  Management  Services 

These  services  support  the  definition,  storage,  and  retrieval  of  data  elements  from 
monolithic  and  distributed,  relational  Database  Management  Systems  (DBMSs). 
These  services  also  support  platform-independent  file  management  (e.g.,  the 
creation,  access,  and  destruction  of  files  and  directories).  The  ARITA  follows  the 
JTA  which  mandates  conformance  to  Entry  level  ANSI  Structured  Query 
Language  (SQL)  standards  and  adds  Ada  interfaces.  The  standards  for  ARITA 
are: 


•  Mandated:  JTA  Section  2.2.2. 1.3,  Data  Management  Services 

•  ISO  9075  SQL 

•  ANSI  X3.168  Embedded  SQL 

•  ISO  12227:  1994,  SQL  Ada  Module  Description  Language 

•  FIPS  Pub  156  (IRDS)  Data  Dictionary 

•  Emerging:  JTA  Section  2.3.3,  Data  Management 

4.4.5  Data  Interchange  Services 

The  data  interchange  services  provide  specialized  support  for  the  exchange  of 
data  and  information  between  applications  and  to  and  from  the  external 
environment.  These  services  include  document,  graphics  data,  geospatial  data, 
imagery  data,  product  data,  audio  data,  video  data,  atmospheric  data, 
oceanographic  data,  and  compression  interchange  services. 

The  ARITA  follows  the  JTA  for  the  following  mandated  standards.  Emerging 
standards  are  identified  in  JTA  Section  2.3.4. 

•  Document  data:  JTA  Section  2.2.2. 1 .4. 1 

•  Graphics  data:  JTA  Section  2.2.2. 1.4.2 

•  Geospatial  data:  JTA  Section  2.2.2. 1 .4.3 

•  Imagery  data:  JTA  Section  2.2.2. 1 .4.4 
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•  Product  data:  JTA  Section  2.2.2. 1 .4.5 

•  Audio  data:  JTA  Section  2.2.2. 1.4.6 

•  Video  data:  JTA  Section  2. 2.2. 1.4.7 

•  Atmospheric  data:  JTA  Section  2.2.2. 1 .4.8 

•  Oceanographic  data:  JTA  Section  2.2.2. 1.4.9 

•  Compression:  JTA  Section  2.2.2.1.4.10 

Additional  standards  for  data  interchange  services  that  apply  to  imagery-related 
systems  are  identified  in  Section  4  of  the  USIS  Standards  and  Guidelines 
document,  Version  1,  dated  13  October  1995. 

Message  standards  for  airborne  reconnaissance  reporting  functions  are  cited  in 
ARITA  Sections  3.7.1  and  3.7.2. 

4.4.6  Graphics  Services 

These  services  support  the  creation  and  manipulation  of  graphics.  They  include 
device-independent,  multidimensional  graphic  object  definition,  and  the 
management  of  hierarchical  database  structures  containing  graphics  data.  The 
ARITA  follows  the  JTA  which  mandates  standards  for  non-COTS  graphics 
development  in  JTA  Section  2.2.2. 1.5,  Graphics  Services.  Additional  standards 
for  the  ARITA  are: 

•  MIL-STD-2525  Graphic  Situation  Display  (GSD)  (Icons/symbology) 

•  USIS  Standards  and  Guidelines  document,  Version  1,  dated  13 
October  1995,  Section  4  provides  additional  standards  for  graphics 
services  that  apply  to  imagery-related  systems. 

4.4.7  Communications  Services 

These  services  support  the  distributed  applications  that  require  data  access  and 
applications  interoperability  in  networked  environments.  The  mandated  and 
emerging  standards  identified  in  Section  3  of  the  JTA  apply  to  the  ARITA. 
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4.4.8  Internationalization  Services 

The  internationalization  services  provide  interfaces  that  allow  a  user  to  define, 
select,  and  change  between  different  culturally  related  application  environments 
supported  by  the  particular  implementation.  These  services  include  character  sets, 
data  representation,  cultural  convention,  and  native  language  support.  The 
standards  mandated  in  Section  2.2.2.2.1  of  the  JTA  apply  to  the  ARITA. 

4.4.9  Security  Services 

These  services  assist  in  protecting  information  and  processing  platform  resources. 
They  must  often  be  combined  with  security  procedures,  which  are  beyond  the 
scope  of  the  information  technology  service  areas,  to  fully  meet  security 
requirements.  Security  services  include  security  policy,  accountability,  assurance, 
user  authentication,  access  control,  data  integrity  and  confidentiality,  non¬ 
repudiation,  and  system  availability  control.  The  mandated  and  emerging 
standards  identified  in  Section  6  of  the  JTA  apply  to  the  ARITA. 

4.4.10  System  Management  Services 

These  services  provide  capabilities  to  manage  the  Application  Platform  Entity 
(Section  4.4),  its  resources  and  users.  System  management  services  include 
configuration  management,  performance  management,  and  fault  management. 
There  are  no  standards  currently  mandated  for  systems  management  in  the  JTA 
(Section  2.2.2.23).  Additional  standards  that  apply  to  the  ARITA  are: 

•  NMF  Omnipoint  1 

4.4.11  Distributed  Computing  Services 

These  services  allow  various  tasks,  operations,  and  information  transfers  to  occur 
on  multiple,  physically-  or  logically-  dispersed,  computer  platforms.  These 
services  include  but  are  not  limited  to  global  time;  data,  file  and  name  services; 
thread  services;  and  remote  process  services.  In  addition  to  the  standards 
mandated  in  the  JTA  Section  2.2.2.2.4,  the  ARITA  mandates: 

•  ISO  9579-1,  2:1993  Remote  Data  Access  (RDA) 
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4.5  External  Environment  Entity 

An  external  environment  entity  exchanges  information  with  the  application 
platform.  These  entities  include  system  users  (e.g.,  operators)  with  information 
interchange  through  a  keyboard,  display  monitor,  mouse,  track  ball,  etc.; 
information  interchanges  (e.g.,  tape  drives,  disk  drives,  etc.),  and  networking 
(e.g.,  terrestrial  landlines,  satellite  circuits,  data  links,  LANs,  etc.).  As  with  the 
JTA,  standards  in  this  area  will  be  addressed  in  a  later  version  of  the  ARITA. 

4.6  Application  Program  Interfaces 

An  application  software  entity  communicates  with  the  Application  Platform 
Entity  though  application  program  interfaces  (APIs).  Application  portability, 
system  interoperability,  and  application  interoperability  can  be  realized  through 
use  of  standardized  APIs. 

The  Reference  Model  API  is  based  on  the  POSIX.O  API,  as  defined  in  the  Draft 
Guide  to  POSIX Open  Systems  Environment,  IEEE  PI 003.0  (also  known  as 
POSIX.O),  which  has  four  (4)  parts: 

•  System  Services  API 

•  Human-Computer  Interaction  API 

•  Information  Services  API 

•  Communications  Services  API 

Standards  in  this  area  will  be  addressed  in  a  later  version  of  the  ARITA. 

4.6.1  System  Services  API 

The  System  Services  API  provides  access  to  resources  that  are  internal  to  the 
application  platform  entity.  These  include  API’s  for  Software  Engineering 
Services  and  Operating  System  Services.  Two  such  services  are  listed  below: 

•  Programming  language  support  services,  which  provide  for  program 
control,  math  functions  (e.g.,  IEEE  754  Floating  Point),  string 
manipulation,  etc.,  through  a  programming  language  API. 
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•  Language-independent  services,  which  provide  for  inter-process 
communications,  inter-object  messaging,  access  to  the  user  interface, 
data  storage,  etc.,  through  language-binding  APIs. 

Standards  in  this  area  will  be  addressed  in  a  later  version  of  the  ARITA. 

4.6.2  Human/Computer  Interaction  Services  API 

The  Human-Computer  Interaction  Services  API  supports  User  Interface  and 
Graphics  Services.  Access  to  other  services  in  the  TRM  are  provided  through  the 
User  Interface  Services.  Standards  in  this  area  will  be  addressed  in  a  later  version 
of  the  ARITA. 

4.6.3  Information  Services  API 

The  Information  Services  API  supports  Data  Management  and  Data  Interchange 
Services.  Standards  in  this  area  will  be  addressed  in  a  later  version  of  the  ARITA. 

4.6.4  Communications  API 

The  Communications  Services  API  supports  services  associated  with 
Communications  Services. 

Many  application  platform  entities  will  interact  through  communications 
networks  that  are  part  of  the  external  environment.  Application  software  entities 
typically  will  request  access  to  communications  services  through  an  API  that  will, 
in  turn,  take  the  appropriate  action  at  the  EEI  to  provide  requested  connectivity. 
Communication  will  then  occur  via  external  entities  that  provide  data  transport 
functions.  By  providing  distributed  computing  through  a  standardized  API,  the 
distributed  system  can  be  viewed  by  a  user  and  by  an  application  software  entity 
as  being  only  a  single  application  platform  entity. 

Standards  in  this  area  will  be  addressed  in  a  later  version  of  the  ARITA. 

4.7  External  Environment  Interfaces 

The  EEIs  are  the  interfaces  with  which  the  application  platform  entity  exchanges 
information  with  the  outside  world,  whether  that  outside  world  is  a  user,  a 
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peripheral  storage  device,  communications  system/network,  or  another 
application  platform  entity.  There  are  three  (3)  types  of  EEIs  provided  by  the 
application  platform  entity: 

•  Human-Computer  Interaction  (HCI)  Services  EEI  (User/Human) 

•  Information  Services  EEI  (Messages,  Database  exchange,  Secondary 
Imagery,  voice,  video,  etc.) 

•  Network  Services  EEI  (Communications  System/Network) 

Standards  in  this  area  will  be  addressed  in  a  later  version  of  the  ARITA. 

4.7.1  HCI  Services  EEI 

The  HCI  Services  EEI  is  the  physical  interface  across  which  interaction  between 
the  application  platform  and  the  human  user  takes  place.  As  such,  it  includes, 
display  monitors,  keyboards,  mouse,  track  balls,  joysticks,  printers,  removable 
disk/tapes,  and  additional  input/output  devices  (e.g.,  scanners,  digitizers). 
Standardization  of  this  interface,  as  is  the  general  trend,  allows  the  user  to  access 
the  services  of  multiple  systems  with  relative  ease  and  access  the  services  of 
compliant  systems  without  retraining. 

4.7.2  Information  Services  EEI 

The  Information  Services  EEI  defines  the  boundary  across  which  external 
peripheral,  persistent  information  storage  is  provided  and  where  standards  for 
format  and  syntax  need  be  defined  for  data  portability  and  interoperability. 
Examples  of  the  types  of  devices  to  which  these  interfaces  are  found  include 
diskettes,  hard  disks,  and  CD-ROM,  write-once  read-many  (WORM),  Electro- 
Optical  (EO),  and  Magneto-Optical  (MO)  drives. 

Standards  in  this  area  will  be  addressed  in  a  later  version  of  the  ARITA. 

4.7.3  Network  Services  EEI 

The  Network  Services  EEI  supports  services  for  interaction  between  application 
software  entities,  running  on  the  local  application  platform,  (e.g.,  single  board 
computers)  with  remote  application  platforms  and  application  software  entities 
running  on  them.  Thus,  it  provides  support  for  external  data  transport  facilities 
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and  devices  using  standards  for  protocol  state,  syntax,  and  format  to  ensure 
application  interoperability  through  the  application  platform(s).  When  the 
application  platform  is  a  device  such  as  a  single  board  computer  or  a  memory  unit 
then  the  EEI  may  be  a  set  of  backplane  standards  such  as  VME  Bus. 

•  ANSI/VITA  64 VME  (6U  circuit  cards) 

Additional  standards  in  this  area  will  be  addressed  in  a  later  version  of  the 
ARITA. 
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5.  Follow-On  ARITA  Activities 


The  following  subsections  summarize  the  key  initiatives  required  for  further 
development  of  the  ARITA.  Some  of  the  initiatives  are  currently  on-going  and 
some  are  new  initiatives  recommended  by  the  ARITA  Working  Group. 

5.1  Integrated  Airborne  Imagery  Architecture 

This  proposed  initiative  would  focus  on  the  IMINT  front-end  and  high- 
performance  processing  functions  defined  in  the  ARITA  FRM.  An  integrated 
airborne  imagery  architecture  (similar  to  JASA)  would  enable  greater  flexibility 
in  equipping  the  airborne  reconnaissance  fleet  through  commonality  and 
enhanced  interoperability.  For  example,  sensor  suites  could  be  highly 
interchangeable  among  multiple  platforms  and  more  tightly  integrated  with  other 
subsystems  to  beneficially  affect  inter-system  cross  cueing.  In  this  architecture, 
planned  sensor  suites  (IR,  EO,  SAR,  S  AR/MTI,  MSI,  and  video)  would  be 
modular  and  interoperable  with  existing  and  planned  airborne  platforms. 

Emphasis  would  be  placed  on  all-weather  platform  and  sensor  capabilities  with 
room  for  specialized  platforms  and  sensors  as  required.  The  common  imagery 
ground/surface  systems  would  be  able  to  process,  exploit,  and  report  on  imagery 
and  imagery-derived  information  irrespective  of  sensor  or  platform  type. 
Workstations  interconnected  by  local  or  wide  area  networks  would  operate  in 
such  a  manner  that  common  routines  would  be  transparent  for  cross-service  users, 
while  accommodating  specialized  procedures  for  mission  specific  needs.  The 
common,  interoperable,  modular,  and  scaleable  elements  of  this  architecture 
would  provide  the  highest  degree  of  flexibility  needed  to  support  the  warfighter  in 
unpredictable  future  mission  scenarios. 

5.1.1  Video  Metadata 

The  CIO-chaired  Video  Working  Group  (VWG)  was  formed  in  July  1995  to 
define  standards  for  video  imagery  data  formats,  metadata  formats  and 
compression  algorithms,  and  address  overall  end-to-end  quality  standards.  A 
VWG  subgroup  was  formed  in  February  96  to  analyze  current  tasking,  reporting, 
exploitation,  and  dissemination  system  requirements  for  video  metadata.  The 
metadata  group  is  also  actively  engaged  with  CIO’s  Accelerated  Architecture 
Acquisition  Initiative  (A3 1)  Program  Office  on  archive  and  retrieval  requirements 


Page  99 

DRAFT 


DRAFT 


for  video  metadata.  The  initial  plan  is  to  develop,  in  coordination  with  the  DARO, 
minimum  metadata  standards  for  collection  system(s)  to  provide  with  the,  video 
imagery  by  Fall  96,  followed  by  a  migration  plan  for  enhancements  to  video 
metadata  to  reflect  SPIA  requirements. 

•  Terminology.  Metadata  is  information  about  the  video,  not  information 
in  the  video.  Other  terms  used  in  describing  metadata  include:  support 
data,  auxiliary  data,  annotation  data,  ancillary  data,  as  well  as  the 
exploitation  support  data  (ESD)  and  ephemeral  data  generally 
associated  with  satellite  derived  imagery. 

•  Elements.  Some  of  the  information  contained  in  “data  about  the  data” 
or  data  about  the  video  as  provided  by  the  National  Exploitation 
Laboratory  (NEL)  include:  location  of  the  image  with  respect  to  the 
ground  via  UTM  or  latitude-longitude  coordinates,  data  and  time  the 
image  was  taken,  north  indicator  on  the  image,  location  accuracy,  and 
map  reference.  This  information  must  be  associated  with  or  “tagged” 
to  the  image  frame.  Other  aspects  of  metadata  include:  positional 
element  or  information  related  to  the  geolocation  of  the  imagery  being 
acquired,  (e.g.,  position,  heading  of  the  air  vehicle);  status  element  or 
information  regarding  the  characteristics  of  the  imagery  being  acquired 
(e.g.,  sensor  being  acquired,  compression  mode);  and  interpreted 
element  or  information  the  user  adds  to  the  data  stream  (e.g.,  audio 
annotation,  content  tagging).  The  following  information  also  may  be 
included  as  part  of  the  metadata  description:  plane  position,  roll,  pitch, 
heading,  gimbal  elevation,  azimuth,  altitude-mean  sea  level  is 
provided  (requires  elevation  source),  GPS  time  and  date,  camera  fields 
of  view  booth  vertical  and  horizontal,  compression  mode,  sensor  being 
sent,  and  communications  link. 

•  Transmission.  Metadata  can  be  down  linked  from  the  platform  via  a 
separate  channel  or  as  part  of  the  image,  if  imagery  format  allows  it. 

•  Retrieval.  Query  data  (part  metadata  and  part  data  inputted  on  the 
ground)  necessary  to  retrieve  imagery  and  imagery  products  include: 
target  location,  target  type,  date  and  time  of  the  image,  quality  of  the 
image  (NIIRS),  country  code,  target  name,  number  of  targets  by  type, 
and  weather  conditions. 
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5.2  Joint  Airborne  MASINT  Architecture 

The  Joint  Airborne  MASINT  Architecture  is  a  new  and  much  needed  effort  to 
define  the  overall  architecture  for  airborne  MASINT  systems.  It  is  organized 
around  seven  broadly  defined  MASINT  functional  areas  of  sensor  systems: 

•  Chemical  and  Biological  Weapons  (CBW) 

•  LASINT/Laser  Warning  Receivers  (LWR) 

•  Unattended  Ground  Sensors  (UGS) 

•  Spectral  (Non-literal) 

•  Air  Sampling 

•  Radio  Frequency  (RF) 

•  Synthetic  Aperture  Radar  Phase  History  (SAR  PH) 

SAR  and  Spectral  overlap  with  the  Airborne  Imagery  Architecture  initiatives,  and 
RF  overlaps  with  the  ongoing  JASA  development  activities. 

Traditional  MASINT  systems  have  been  unique,  stand  alone  systems  that  required 
extensive  post  processing  and  analysis  to  supply  information  of  intelligence  value. 
Now  that  MASINT  technologies  are  rapidly  maturing,  much  of  this  processing 
has  become  real-time  and  is  often  incorporated  within  the  sensor  sub-processing 
system  for  immediate  use.  In  addition,  MASINT  has  developed  multiple  sensor 
correlation  systems  to  provide  real-time  target  identification  (automatic  target 
recognition).  These  systems  are  quickly  evolving  to  highly  capable  multiple¬ 
sensor  “smart  systems”  that  can  provide  identification  and  location  coordinates  to 
sensor-to-shooter  systems.  The  Central  MASINT  Office  (CMO)  will  be 
developing  a  flexible  architecture  over  the  next  couple  of  years  that  will  maximize 
interoperability  through  standard  hardware  and  software  interfaces  that  will 
streamline  the  integration  of  new  MASINT  systems  as  they  come  on  line. 

It  is  also  CMO’s  intent  to  create  standards  for  MASINT  systems  that  allow  for 
growth  and  technical  innovation  to  reduce  acquisition  and  training  times,  increase 
capability,  and  lower  long-term  costs.  The  key  is  to  identify  areas  between 
systems  that  serve  common  functions  and  therefore,  lend  themselves  to  degrees  of 
commonality  and  interoperability. 
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5.3  MASINT  Ground/Surface  System  Architecture 

MASINT  does  not  have  any  dedicated  ground/surface  systems  at  present.  Instead, 
data  is  either  processed  in  real-time  on-board  the  platform  or  it  is  recorded  for 
non-real-time  processing  in  laboratory  facilities.  Within  the  DARO  Objective 
Architecture  2010,  all  ground  processing  and  dissemination  functions  will  be 
migrating  towards  the  Distributed  Common  Ground  Station  (DCGS).  MASINT 
will  most  likely  evolve  quickly  towards  the  DCGS  and  immediately  adopt  the 
hardware  and  software  configurations  within  this  document.  In  the  near  term, 
MASINT  systems  will  merge  with  SIGINT  and  IMINT  where  possible  for  ground 
processing.  MASINT  systems  that  are  similar  or  common  with  the  IMINT  CIGSS 
architecture  will  adopt  the  CIGSS  standards.  CIGSS  has  a  multi-INT  processor 
function  that  is  the  main  tie  between  the  two  disciplines.  On  the  RF  side, 

MASINT  will  leverage  the  JASA  architecture  established  to  develop  common 
standards.  The  rest  of  the  MASINT  systems  could  eventually  evolve  to  provide 
data  through  the  Joint-STARS  Common  Ground  Station  and  disseminate  through 
GCCS/TIBS  as  the  DCGS  comes  on  line.  The  notional  concept  of  a  Common 
MASINT  Ground/Surface  System  will  require  considerable  effort  to  reach  an 
effective  near  term  solution  with  a  migration  strategy  towards  the  eventual  DCGS. 

5.4  Distributed  Common  Ground/Surface  System  Architecture 

A  migration  strategy  for  IMINT,  MASINT,  SIGINT,  and  multi-intelligence 
ground/surface  systems  to  the  Distributed  Common  Ground/Surface  System 
(DCGSS)  is  planned.  The  DCGSS  evolution  will  reflect  continuing  commonality, 
interoperability,  modularity,  and  scalability  efforts.  The  DCGSS  strategy  and 
architecture  will  unify  the  subsystems  and  components  in  current  stove-piped 
ground/surface  systems.  The  CIGSS  architecture  and  standards  referenced  in 
Section  2.2.2  is  the  first  step  in  this  strategy.  The  migration  to  DCGSS  will 
introduce  common  imagery,  SIGINT,  and  MASINT  processors,  field  one 
scaleable  and  modular  workstation  type,  develop  one  database  system  tailored,  via 
software,  to  handle  different  mission  requirements  and  multi-echelon  needs,  and 
provide  common  communications  interfaces  able  to  keep  pace  with  developing 
C4I  for  the  Warrior  concepts  and  architectures. 


Page  102 

DRAFT 


DRAFT 


5.5  Integrated  Communications  Architecture 

The  proposed  integrated  communications  architecture  would  reflect  ongoing 
initiatives  to  achieve  interoperability  through  selection  of  standard  message  and 
data  formats  and  signal  waveforms  for  both  collection  and  dissemination  data 
links  between  ground,  air  and  satellite  systems.  The  communications  architecture 
would  also  show  the  interrelationships  of  the  following  components: 

•  Overall  data  flow  and  ISR  products  produced  by  airborne 
reconnaissance  systems 

•  The  Common  Data  Link  (CDL)  and  Airborne  Information 
Transmission  (ABIT)  programs 

•  Link  16  dissemination  and  other  intelligence  broadcast  links  (TDDS, 
TADIXS-B,  TIBS,  TRIXS,  IBS) 

•  UHF  Communications  (TACSAT/DAMA,  LOS,  HQ  I/HQ  II,  Saturn) 

•  Commercial  SATCOM  (Ku  Band,  Ka  Band,  IMARSAT,  etc.) 

•  Communications  Infrastructure  and  Networks  (IP  Router  Networks, 
Intelink,  GBS,  etc.) 
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List  of  Acronyms 


A/D 

A3I 

ABIT 

ACTD 

AFMSS 

AGL 

AOC 

AOR 

API 

ARL 

ARTA 

ARTAWG 

ASARS 

ASAS 

ATA 

ATARS 

ATC 

ATD 

ATO 

ATR 

AUTODIN 

AWE 

BCD 

C2 

C3I 

C4I 

c4isr 

CASE 


Analog  to  Digital 

Accelerated  Architecture  Acquisition  Initiative 

Airborne  Imagery  Transmission 

Advanced  Concept  and  Technology  Demonstration 

Air  Force  Mission  Support  System 

Above  Ground  Level 

Air  Operations  Center 

Atlantic  Ocean  Region,  Area  of  Operational  Responsibility 
Application  Program  Interface 
Airborne  Reconnaissance  Low 

Airborne  Reconnaissance  Technical  (Information)  Architecture 

Airborne  Reconnaissance  Technical  (Information)  Architecture 
Working  Group 

Advanced  Synthetic  Aperture  Radar  System 

All  Source  Analysis  System 

Army  Technical  Architecture 

Advanced  Tactical  Airborne  Reconnaissance  System 

Automatic  Target  Cueing 

Advanced  Technology  Demonstration 

Air  Tasking  Order 

Automatic  Target  Recognition 

Automatic  Digital  Network 

Avionics/W  eapons/Electronics 

Binary  Coded  Decimal 

Command  and  Control 

Command,  Control,  Communications  and  Intelligence 
Command,  Control,  Communications,  Computers,  and  Intelligence 

Command,  Control,  Communications,  Computers,  and  Intelligence 
Surveillance  and  Reconnaissance 

Computer  Aided  Software  Engineering 
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List  of  Acronyms,  continued 


CBW 

CCD 

CCIR 

CDE 

CDL 

CGI 

CIGSS 

CINC 

CIP 

CIS 

CJCSI 

CMA 

CMO 

COE 

COMINT 

CONOPS 

COTS 

CSE 

CSMA 

CTT 

DAFIF 

DAMA 

DARO 

DARP 

DARSC 

DBMS 

DBS 

DCE 

DCGS 

DCGSS 

DCRSi 

DCT 

DCW 


Chemical  and  Biological  Weapons 

Charge-Coupled  Device 

CoChannel  Interference  Reduction 

Common  Desktop  Environment 

Common  Data  Link 

Computer  Graphics  Interface 

Common  Imagery  Ground/Surface  System 

Commander  In  Chief 

Common  Imagery  Processor 

Combat  Information  System 

Chairman  Joint  Chiefs  of  Staff  Instruction 

Collection  Management  Authority 

Central  MASINT  Office 

Common  Operating  Environment 

Communications  Intelligence 

Concept  of  Operations 

Comercial  Off-the-Shelf 

Client  Server  Environment 

Carrier  Sense  Multiple  Access 

Commanders  Tactical  Terminal 

Digital  Aeronautical  Flight  Information  File 

Demand  Assigned  Multiple  Access 

Defense  Airborne  Reconnaissance  Office 

Defense  Airborne  Reconnaissance  Program 

Defense  Airborne  Reconnaissance  Steering  Committee 

Database  Management  System 

Direct  Broadcast  Service 

Distributed  Computing  Environment 

Distributed  Common  Ground  Station 

Distributed  Common  Ground/Surface  System 

Digital  Channel  Recorder  System  -  Improved 

Discrete  Cosine  Transform 

Digital  Chart  of  the  World 
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List  of  Acronyms,  continued 


DDN 

Defense  Data  Network 

DF 

Direction  Finding 

DFAD 

Digital  Features  Analysis  Data 

DIA 

Defense  Intelligence  Agency 

DIAL 

Differential  Absorption  LIDAR 

DII 

Defense  Information  Infrastructure 

DISA 

Defense  Information  System  Agency 

DMA 

Defense  Mapping  Agency 

DMS 

Defense  Message  Service 

DNC 

Digital  Nautical  Chart 

DoD 

Department  of  Defense 

DPPDB 

Digital  Point  Positioning  Database 

DSCS 

Defense  Satellite  Communiction  System 

DSP 

Digital  Signal  Processing 

DSS 

Direct  Satellite  Service  (DBS) 

DTED 

Digital  Terrain  Elevation  Data 

DTSR 

Digital  Temporary  Storage  Recorder 

ECHUM 

Electronic  Chart  Updating  Manual 

EEI 

External  Environment  Interface 

EHF 

Extra  High  Frequency 

ELA 

Electronic  Industries  Association 

ELINT 

Electronic  Intelligence 

EO 

Electro-Optical 

ESD 

Exploitation  Support  Data 

ESM 

Electronic  Support  Measures 

ETRAC 

Enhanced  Tactical  Radar  Correlator 

FC 

Fiber  Channel 

FC-PH 

Fibre  Channel  Physical  and  Signaling  Interface 

FDOA 

Frequency  Difference  of  Arrival 

FFT 

Fast  Fourier  Transform 

FIPS 

Federal  Information  Processing  Standard 

FLIR 

.  Forward  Looking  Infrared 

FOPEN 

Foliage  Penetration 
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FOWG 

FRM 

FTIR 

GBS 

GCCS 

GCSS 

GHz 

GOTS 

GPS 

GSD 

HAE 

HCI 

HDTV 

HF 

HIPPI 

HSI 

HTML 

HUMINT 

Hz 

I&Q 

IBS 

IDB 

IDEF 

IEC 

LESS 

IF 

IFF 

IFSAR 

IMINT 

IMS 

INMARSAT 

INS 

INT 


Fiber-Optic  Wave  Guide 
Functional  Reference  Model 
Fourier  Transform  Infrared 
Global  Broadcast  System 
Global  Command  and  Control  System 
Global  Combat  Support  System 
Giga  Hertz 

Government  Off-the- Shelf 
Global  Positioning  System 
Graphic  Situation  Display 
High  Altitude  Endurance 

Human-Computer  Interface,  Human-Computer  Interaction 
High  Definition  Television 
High  Frequency 

High  Performance  Parallel  Interface 
Hyperspectral  Imagery 
Hyper  Text  Mark-up  Language 
Human  Intelligence 
Hertz 

In-phase  and  Quadrature 
Integrated  Broadcast  System 
Integrated  Database 
Integrated  Definition 

International  Electrotechnical  Commission 
Imagery  Exploitation  Support  System 
Intermediate  Frequency 
Identification  Friend  or  Foe 
Interferometric  Synthetic  Aperture  Radar 
Imagery  Intelligence 
Ion  Mobility  Spectrometer 
International  Maritime  Satellite 
Inertial  Navigation  System 
Intelligence 
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IP 

Internet  Protocol 

IPA 

Image  Product  Archive 

IPI 

Intelligent  Peripheral  Interface 

IPL 

Image  Product  Library 

IR 

Infrared 

IRDS 

Information  Resource  Dictionary  System 

IRIG 

Intra  Range  Instrumentation  Group 

ISAR 

Inverse  Synthetic  Aperature  Radar 

ISB 

Intelligence  Systems  Board 

ISMC 

Imagery  Standards  Management  Committee 

ISR 

Intelligence,  Surveillance,  and  Reconnaissance 

IT 

Information  Technology 

IUGS 

Intemetted  Unattended  Ground  Sensor 

JAC 

Joint  Analysis  Center 

JASA 

Joint  Airborne  SIGINT  Architecture 

jbs 

Joint  Broadcast  Service 

JCMT 

Joint  Collection  Management  Tool 

JCRD 

Joint  Capstone  Requirements  Document 

JCS 

Joint  Chiefs  of  Staff 

JDISS 

Joint  Deployable  Intelligence  Support  System 

JFCC 

Joint  Force  Component  Command 

JFIF 

JPEG  File  Interchange  Format 

JIC 

Joint  Intelligence  Center 

JPEG 

Joint  Photographic  Experts  Group 

JROC 

Joint  Requirements  Oversight  Council 

JSIPS 

Joint  Service  Image  Processing  System 

JTA 

Joint  Technical  Architecture 

JTIDS 

Joint  Tactical  Information  Distribution  System 

JWICS 

Joint  Worldwide  Intelligence  Communications  System 

Ka 

Above  K  band  (20-40  GHz) 

KCOIC 

Korean  Combined  Operations  Intelligence  Center 

KHz 

Kilo  Hertz 

LANDSAT 

Land  Observation  Satellite 
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LASINT 

Laser  Intelligence 

LF 

Low  Frequency 

LIDAR 

Laser  Imaging  Detection  and  Ranging 

LWIR 

Long  Wavelength  Infrared 

LWR 

Laser  Warning  Receivers 

MACOM 

Major  Command 

MAE 

Medium  Altitude  Endurance 

MAGTF 

Marine  Air  Ground  Task  Force 

MASINT 

Measurement  and  Signatures  Intelligence 

MCEB 

Military  Communications  Electronic  Board 

MET 

Meteorological 

MIDS 

Multi-functional  Information  Distribution  System 

MIES 

Modernized  Imagery  Exploitation  System 

MUDS 

Military  Imagery  Intelligence  Database  System 

MO 

Magneto-Optical 

MPEG 

Motion  Picutre  Expert  Group 

MSI 

Multi-Spectral  Imagery 

MSL 

Mean  Sea  Level 

MTI 

Moving  Target  Indicator 

MWIR 

Middle  Wavelength  Infrared 

NEL 

National  Exploitation  Laboratory 

NIIRS 

National  Imagery  Interpretability  Scale 

NIPRNET 

Non-secure  Internet  Protocol  Router  Network 

NIR 

Near  Infrared 

NITFS 

National  Imagery  Transmission  Format  Standards 

NRL 

Naval  Research  Laboratory 

NRO 

National  Reconnaissance  Agency 

NSA 

National  Security  Agency 

NSRL 

National  SIGINT  Requirements  List 

NTSC 

National  Television  Standards  Committee 

OASD 

Office  of  Assistant  Secretary  of  Defense 

OB 

Order  of  Battle 

ODMG 

Object  Database  Management  Group 
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O  M  A  Obj  ect  Management  Architecture 

OMG  Object  Management  Group 

OODBMS  Object-Oriented  DataBase  Management  System 

OP WG  Optical  Planar  W ave  Guide 

OSD  Office  of  the  Secretary  of  Defense 

OSF  Open  Software  Foundation 

PAN  AMS  AT  Pan  American  Satellite 


PEO 

PH 

PHD 

PHIGS 

PM 

POSIX 

PPS 

PVOD 

RC 

RCS 

RDA 

RF 

RMS 

SAE 

SAR 

SATCOM 

SAW 

SCSI 

SEI 

SIGINT 

SIPRNET 

SMPTE 

SNUTR 

SOFPARS 

SPIA 

SPO 


Program  Executive  Officer 
Phase  History 
Phase  History  Data 

Programmer  Hierarchical  Interactive  Graphics  System 
Program  Manager 

Portable  Operating  System  Interface  for  Computer  Environments 
Pulse  Per  Second 

Probabilistic  Vertical  Obstruction  Data 

Remote  Controls 

Radar  Cross  Section 

Remote  Data  Access 

Radio  Frequency 

Requirements  Management  System 
Service  Acquisition  Executive 
Synthetic  Aperture  Radar 
Satellite  Communications 
Surface  Acoustic  Wave 
Small  Computer  System  Interface 
Specific  Emitter  Identification 
Signals  Intelligence 

Secure  Internet  Protocol  Router  Network 

Society  of  Motion  Picture  and  Television  Engineers 

SIGINT  Numerical  Tasking  Requirement 

Special  Operations  Forces  Planning  and  Rehearsal  System 

Standards  Profile  for  Imagery  Access 

System  Program  Office 
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SQL 

Structured  Query  Language 

SRO 

Sensitive  Reconnaissance  Operation 

SWTR 

Short  Wavelength  Infrared 

TACSAT 

Tactical  Satellite 

TADIXS 

Tactical  Data  Information  Exchange  System 

TAFIM 

Technical  Architecture  Framework  for  Information  Management 

TAMPS 

Tactical  Aviation  Mission  Planning  System 

TBD 

To  Be  Determined 

TCP 

Transport  Control  Protocol 

TDDS 

TRAP  Data  Dissemination  System 

TDL 

Tactical  Data  Link 

TDMA 

Time  Division  Multiple  Access 

TDOA 

Time  Difference  of  Arrival 

TEG 

Tactical  Exploitation  Group 

TIBS 

Tactical  Information  Broadcast  Service 

TRAP 

TRE  and  Related  Applications 

TRE 

Tactical  Receive  Equipment 

TRIXS 

Tactical  Reconnaissance  Intelligence  Exchange  System 

TRM 

Technical  Reference  Model 

UAV 

Unmanned  Aerial  Vehicle 

UDP 

User  Datagram  Protocol 

UGS 

Unattended  Ground  Sensor 

USAF 

United  StatesAir  Force 

USI 

Ultra-Spectral  Imagery 

USIS 

United  States  Imagery  System 

USMTF 

U.S.  Message  Text  Format 

USN 

United  States  Navy 

USNO-UTC 

United  States  Naval  Observatory  -  Coordinated  Universal  Time 

UTM 

Universal  Transverse  Mercator 

VHS 

Video  Helical  Scan  Recording  Standard,  Video  Home  System 

VIQCB 

Video  Imagery  Quality  Control  Board 

VITC 

.  Vertical  Interval  Time  Code 

YITD 

Vector  Product  Interim  Terrain  Data 
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VMAP 

Vector  Map 

VME 

Versa  Module  European 

VMF 

Variable  Message  Format 

VWG 

Video  Working  Group 

WAM 

Wide  Area  Munitions 

WGS-84 

World  Geodetic  Survey  1984 

WORM 

Write-Once  Read-Many 

WWMCCS 

World-Wide  Military  Command  and  Control  System 

A-9 


